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

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 (например, COST, CHOOSE и т. Д.) И частота выполнения вашей статистики.

Пример 1:

СКАН http://docs.google.com/a/shanghainetwork.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

На самом деле для подобных проблем лучше всего сделать ASKTOM . В частности, его ответ на этот вопрос содержит ссылки на онлайн-документацию по Oracle, где объясняется множество правил такого рода.

Одна вещь, которую нужно иметь в виду, это то, что объяснять планы - действительно лучшие предположения.

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

Но вы должны ASKTOM. Он знает все об этом:)

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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

С http://www.sql -server-performance.com / tips / query_execution_plan_analysis_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 10

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