Как вы интерпретируете план объяснения запроса?

Question

Пытаясь понять, как выполняется оператор SQL, иногда рекомендуется просмотреть план объяснения.Какой процесс следует пройти при интерпретации (осмыслении) плана объяснения?Что должно выделяться как: «О, это работает великолепно?» против «О, нет, это не так».

Answer 1

Я вздрагиваю всякий раз, когда вижу комментарии о том, что полное сканирование таблиц — это плохо, а доступ к индексу — это хорошо.Полное сканирование таблицы, сканирование диапазона индексов, быстрое полное сканирование индекса, вложенные циклы, соединение слиянием, хэш-соединение и т. д.Это просто механизмы доступа, которые аналитик должен понимать и сочетать со знанием структуры базы данных и цели запроса, чтобы прийти к какому-либо значимому выводу.

Полное сканирование — это просто наиболее эффективный способ чтения большой части блоков сегмента данных (таблицы или (под)раздела таблицы), и, хотя оно часто может указывать на проблему с производительностью, это происходит только в контексте того, является ли это эффективным механизмом достижения целей запроса.Говоря как специалист по хранилищам данных и бизнес-аналитике, мой предупреждающий сигнал номер один по производительности — это метод доступа на основе индекса и вложенный цикл.

Итак, для механизма чтения плана объяснения хорошим руководством является документация Oracle: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Также внимательно прочтите Руководство по настройке производительности.

Также имейте в Google «обратную связь по мощности», метод, в котором план объяснения можно использовать для сравнения оценок мощности на различных этапах запроса с фактическими мощностями, возникающими во время выполнения.Я считаю, что автором метода является Вольфганг Брайтлинг.

Итак, итог:понять механизмы доступа.Разберитесь с базой данных.Поймите цель запроса.Избегайте эмпирических правил.

Answer 2

Эта тема слишком обширна, чтобы ответить на такой вопрос.Вам нужно потратить некоторое время на чтение Руководство Oracle по настройке производительности

Answer 3

В двух примерах ниже показано ПОЛНОЕ сканирование и БЫСТРОЕ сканирование с использованием ИНДЕКСА.

Лучше всего сосредоточиться на стоимости и мощности.Судя по примерам, использование индекса снижает стоимость выполнения запроса.

Это немного сложнее (и у меня нет 100%-ной уверенности в этом), но в основном стоимость — это функция стоимости ЦП и ввода-вывода, а мощность — это количество строк, которые Oracle ожидает проанализировать.Уменьшить и то, и другое – это хорошо.

Не забывайте, что на стоимость запроса может влиять ваш запрос и модель оптимизатора Oracle (например:СТОИМОСТЬ, ВЫБОР и т. д.) и как часто вы ведете статистику.

Пример 1:

СКАНИРОВАНИЕ http://docs.google.com/a/shanghinetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Пример 2 с использованием индексов:

ИНДЕКС http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

И, как уже говорилось, следите за СКАНИРОВАНИЕМ ТАБЛИЦЫ.Обычно вы можете избежать этого.

Answer 4

Поиск таких вещей, как последовательное сканирование, может быть в некоторой степени полезным, но реальность в цифрах...за исключением случаев, когда цифры являются лишь приблизительными!Что обычно далеко более полезно, чем просмотр запроса план смотрит на настоящее исполнение.В Postgres в этом заключается разница между EXPLAIN и EXPLAIN ANALYZE.EXPLAIN ANALYZE фактически выполняет запрос и получает реальную информацию о времени для каждого узла.Это позволяет вам увидеть, что на самом деле происходит, а не то, что планировщик думает случится.Во многих случаях вы обнаружите, что последовательное сканирование вообще не является проблемой, а что-то еще в запросе.

Другой ключевой момент — определить, какой на самом деле дорогостоящий шаг.Во многих графических инструментах используются стрелки разного размера, чтобы указать, сколько стоят различные части плана.В этом случае просто ищите ступеньки, на которых входящие тонкие стрелки и выходящие толстые стрелки.Если вы не используете графический интерфейс, вам придется внимательно следить за цифрами и искать места, где они внезапно становятся намного больше.После небольшой практики становится довольно легко выделить проблемные области.

Answer 5

Действительно, для таких проблем лучше всего АСКТОМ.В частности, его ответ на этот вопрос содержит ссылки на онлайн-документ Oracle, где объясняются многие из подобных правил.

Следует иметь в виду, что планы объяснения на самом деле являются лучшими догадками.

Было бы неплохо научиться использовать sqlplus и поэкспериментировать с командой AUTOTRACE.Имея некоторые точные цифры, вы, как правило, можете принимать более правильные решения.

Но вам следует АСКТОМ.Он все знает :)

Answer 6

Вывод объяснения показывает, сколько времени занял каждый шаг.Первое — найти шаги, которые заняли много времени, и понять, что они означают.Такие вещи, как последовательное сканирование, говорят вам, что вам нужны более качественные индексы - в основном это вопрос исследования вашей конкретной базы данных и опыта.

Answer 7

Одно «О нет, это неправильно» часто имеет форму сканирование таблицы.Сканирование таблиц не использует каких-либо специальных индексов и может способствовать очистке кэшей памяти от всего полезного.Например, в postgreSQL вы обнаружите, что это выглядит так.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

Иногда сканирование таблицы лучше, чем, скажем, использование индекса для запроса строк.Однако это одна из тех тревожных моделей, которые вы, похоже, ищете.

Answer 8

По сути, вы смотрите на каждую операцию и смотрите, «имеют ли они смысл», учитывая ваши знания о том, как она должна работать.

Например, если вы объединяете две таблицы, A и B, в соответствующих столбцах C и D (A.C=B.D), и ваш план показывает сканирование кластеризованного индекса (термин SQL Server - не уверен в термине оракула) в таблице A, затем соединение вложенного цикла с серией поисков по кластеризованному индексу в таблице B, вы можете подумать, что возникла проблема.В этом сценарии вы можете ожидать, что механизм выполнит пару сканирований индекса (по индексам в объединенных столбцах) с последующим объединением слиянием.Дальнейшее расследование может выявить плохую статистику, заставляющую оптимизатор выбрать этот шаблон соединения или индекс, которого на самом деле не существует.

Answer 9

посмотрите на процент времени, потраченного на каждый подраздел плана, и подумайте, что делает движок.например, если он сканирует таблицу, рассмотрите возможность размещения индекса в полях, которые сканируются на наличие

Answer 10

В основном я ищу сканы индексов или таблиц.Обычно это говорит мне о том, что мне не хватает индекса в важном столбце, который находится в оператореwhere или операторе соединения.

От http://www.sql-server- Performance.com/tips/query_execution_plan_anaанализ_p1.aspx:

Если вы видите какое -либо из следующего в плане исполнения, вы должны рассмотреть их предупреждающие знаки и исследовать их на предмет потенциальных проблем с производительностью.Каждый из них не идеален с точки зрения производительности.

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

Это не всегда возможно избегать, но чем больше вы можете избежать их, тем быстрее будет производительность запроса.

Answer 11

Эмпирические правила

(вы, вероятно, тоже захотите прочитать подробности:

• Документы Oracle
• АСКТОМ
• Документация по SQL-серверу
  )

Плохой

Сканирование нескольких больших таблиц

Хороший

Использование уникального индекса
Индекс включает в себя все обязательные поля

Самая частая победа

Примерно в 90% случаев проблем с производительностью, которые я видел, проще всего разбить запрос с большим количеством (4 или более) таблиц на 2 меньших запроса и временную таблицу.