Понимание результатов Выполняется, Объясняет План в Oracle Разработчика SQL
Так что твой код на самом деле работает нормально для меня. Похоже, что это может быть проблемой с версиями пакетов, потому что кажется странным, что вы используете функцию plyr summarise.
Однако, вот немного более краткий способ создания этого графа (и, надеюсь, это полезно для всего, что вы хотите добавить к этому графику)
brfss_2013 %>%
# Add count of income levels first (note this only adds a variable)
add_count(incomeLev) %>%
rename(count_inc = n) %>%
# Count observations per group (this transforms data)
count(incomeLev, mentalHealth, count_inc) %>%
rename(count_mentalHealth = n) %>%
mutate(percent= count_mentalHealth / count_inc) %>%
ggplot(aes(x= incomeLev,
y= count_mentalHealth,
# Technically you don't need this group here but groups can be handy
group= mentalHealth)) +
geom_bar(aes(fill=mentalHealth),
stat="identity")+
# Using the scales package does the percent formatting for you
geom_text(aes(label = scales::percent(percent)), vjust = 1)+
theme_minimal()
[ 113] 4 ответа
Результатом EXPLAIN PLAN является отладка оптимизатора запросов Oracle. COST - это окончательный результат работы оптимизатора на основе затрат (CBO), цель которого - выбрать, какой из множества различных возможных планов следует использовать для выполнения запроса. CBO рассчитывает относительную стоимость для каждого плана, а затем выбирает план с наименьшей стоимостью.
(Примечание: в некоторых случаях CBO не имеет достаточно времени для оценки всех возможных планов; в этих случаях он просто выбирает план с самая низкая из найденных до сих пор затрат)
В общем, один из самых больших вкладов в медленный запрос - это количество строк, прочитанных для обслуживания запроса (если быть более точным, блоков), поэтому стоимость будет основана на в части количества строк, которые необходимо будет прочитать оценки оптимизатора.
Например, допустим, у вас есть следующий запрос:
SELECT emp_id FROM employees WHERE months_of_service = 6;
( Столбец month_of_service имеет ограничение NOT NULL и обычный индекс на нем.)
Оптимизатор может выбрать здесь два основных плана:
- План 1. Прочитать все строки из таблицы «Сотрудники» для каждого проверьте, является ли предикат истинным (
months_of_service = 6). - План 2: прочтите индекс, где
months_of_service = 6(в результате получается набор ROWID) , а затем получить доступ к таблице на основе возвращенных ROWID.
Представим, что таблица «сотрудников» имеет 1 000 000 (1 миллион) строк. Позволять' Далее представьте, что значения для month_of_service варьируются от 1 до 12 и по какой-то причине распределены довольно равномерно.
Стоимость Плана 1 , который включает ПОЛНОЕ СКАНИРОВАНИЕ, будет стоимостью чтения всех строки в таблице сотрудников, что примерно равно 1 000 000; но поскольку Oracle часто может читать блоки, используя многоблочные чтения, фактическая стоимость будет ниже (в зависимости от того, как настроена ваша база данных) - например, давайте представим, что количество многоблочных чтений равно 10 - расчетная стоимость полное сканирование будет 1000000/10; Общая стоимость = 100 000.
Стоимость плана 2 , который включает сканирование диапазона индексов и поиск в таблице по ROWID, будет состоять из стоимости сканирования индекса плюс стоимость доступа к таблице с помощью ROWID. Я выиграл' t вдаваться в расчет стоимости сканирования диапазона индекса, но давайте представим, что стоимость сканирования диапазона индекса составляет 1 на строку; мы ожидаем найти совпадение в 1 из 12 случаев, поэтому стоимость сканирования индекса составляет 1 000 000/12 = 83 333; плюс стоимость доступа к таблице (предположим, что 1 блок чтения за доступ, мы не можем использовать здесь многоблочные чтения) = 83 333; Общая стоимость = 166 666.
Как видите, стоимость Плана 1 (полное сканирование) МЕНЬШЕ, чем стоимость Плана 2 (сканирование индекса + доступ по идентификатору строки), что означает, что CBO выберет ПОЛНОЕ сканирование.
. Если предположения, сделанные здесь оптимизатором, верны, то на самом деле план 1 будет предпочтительнее и намного более эффективен, чем план 2, что опровергает миф о том, что ПОЛНОЕ сканирование «всегда плохо».
The CBO builds a decision tree, estimating the costs of each possible execution path available per query. The costs are set by the CPU_cost or I/O_cost parameter set on the instance. And the CBO estimates the costs, as best it can with the existing statistics of the tables and indexes that the query will use. You should not tune your query based on cost alone. Cost allows you to understand WHY the optimizer is doing what it does. Without cost you could figure out why the optimizer chose the plan it did. Lower cost does not mean a faster query. There are cases where this is true and there will be cases where this is wrong. Cost is based on your table stats and if they are wrong the cost is going to be wrong.
When tuning your query, you should take a look at the cardinality and the number of rows of each step. Do they make sense? Is the cardinality the optimizer is assuming correct? Is the rows being return reasonable. If the information present is wrong then its very likely the optimizer doesn't have the proper information it needs to make the right decision. This could be due to stale or missing statistics on the table and index as well as cpu-stats. Its best to have stats updated when tuning a query to get the most out of the optimizer. Knowing your schema is also of great help when tuning. Knowing when the optimizer chose a really bad decision and pointing it in the correct path with a small hint can save a load of time.
Вот ссылка на использование EXPLAIN PLAN с Oracle: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm ), с конкретная информация о столбцах, найденных здесь: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i18300
Ваше упоминание «FULL» указывает мне что запрос выполняет сканирование всей таблицы для поиска ваших данных. Это нормально, в определенных ситуациях, в противном случае это индикатор плохой индексации / написания запросов.
Как правило, с планами объяснения вы хотите убедиться, что ваш запрос использует ключи, чтобы Oracle мог найти данные, которые вы ищете, с доступом к наименьшему количеству строк. В конце концов, вы можете когда-нибудь так далеко продвинуться только с архитектурой ваших таблиц. Если затраты остаются слишком высокими, возможно, вам придется подумать о корректировке макета вашей схемы, чтобы она была более ориентирована на производительность.
FULL, вероятно, относится к полному сканированию таблицы, что означает, что индексы не используются. Обычно это указывает на то, что что-то не так, если только запрос не должен использовать все строки в таблице.
Стоимость - это число, которое сигнализирует о сумме различных нагрузок, процессора, памяти, диска, ввода-вывода и больших чисел. обычно плохие. Числа суммируются при переходе к корню плана, и каждая ветвь должна быть проверена, чтобы найти узкие места.
Вы также можете запросить v $ sql и v $ session, чтобы получить статистику по операторам SQL, и это будут иметь подробные показатели для всех видов ресурсов, таймингов и исполнений.