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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Ответ 3

Ниже приведены два примера: FULL scan и FAST-сканирование с использованием INDEX.

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

Правила большого пальца

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

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

Bad

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

Хорошо

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

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

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