it-swarm-ru.tech

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

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

87
user290

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

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

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

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

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

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

78
David Aldridge

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

13
Tony Andrews

Два приведенных ниже примера показывают полное сканирование и быстрое сканирование с использованием индекса.

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

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

Не забывайте, что на стоимость запроса может повлиять ваш запрос и модель оптимизатора Oracle (например, COST, CHOOSE и т.д.) И то, как часто вы запускаете статистику.

Пример 1:

SCAN http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

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

INDEX http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

И, как уже предлагалось, следите за TABLE SCAN. Вы можете вообще избежать этого.

5
Mark Nold

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

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

4
decibel

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

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

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

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

3
EvilTeach

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

2
Tom Leys

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

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

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

2
convex hull

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

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

2
Jonathan Rupp

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

1
Steven A. Lowe

Я в основном ищу индексные или табличные сканы. Обычно это говорит мне, что мне не хватает индекса в важном столбце, который находится в операторе 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? 

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

1
dpollock