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

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

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

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

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

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

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

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

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

В приведенных ниже примерах показано ПОЛНОЕ сканирование и сканирование FAST с помощью INDEX.

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

Это немного сложнее (и у меня нет на нем 100% -ного дескриптора), но в основном стоимость – это функция стоимости процессора и ввода-вывода, а количество элементов – количество строк, которое 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. Вы можете вообще избежать этого.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С 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? 

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

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

(вы, вероятно, захотите также ознакомиться с деталями:

  • Документы Oracle
  • ASKTOM
  • Документы SQL Server
    )

Плохо

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

Хорошо

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

Наиболее распространенная победа

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