Планы выполнения SQL основаны на схеме или данных или обоих?

Question

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

Является ли план (и, более конкретно, относительная стоимость процессора), основанная только на схеме, или также фактические данные, которые в настоящее время находятся в базе данных?

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

Я использую SQL Server 2005 и Management Studio длясделать планы

Answer 1

Он будет основан на схеме и данных.Схема сообщает, какие индексы доступны, а Данные говорят, что лучше.

Ответ может меняться в небольших степенях в зависимости от используемой СУБД (вы не указали), но все они ведут статистику поиндексы, чтобы знать, поможет ли индекс.Если индекс разбивает 1000 строк на 900 различных значений, это хороший индекс для использования.Если индекс дает только 3 разных значения для 1000 строк, это не совсем selective, поэтому он не очень полезен.

Answer 2

SQL Server - это оптимизатор, основанный на 100% стоимости. Другие оптимизаторы СУБД обычно представляют собой сочетание затрат и правил, но SQL Server, к лучшему или худшему, полностью ориентирован на затраты. Оптимизатором, основанным на правилах, может быть тот, который может сказать, например, , порядок таблиц в предложении FROM определяет таблицу управления в соединении . В SQL Server нет таких правил. См. Обработка операторов SQL :

Оптимизатор запросов SQL Server - это Оптимизатор на основе затрат. Каждый возможный План выполнения имеет связанную стоимость с точки зрения количества вычислений используемые ресурсы. Оптимизатор запросов должны проанализировать возможные планы и выберите тот с самым низким Ориентировочная стоимость. Какой-то сложный SELECT заявления имеют тысячи возможных планы выполнения. В этих случаях оптимизатор запросов не анализирует все возможные комбинации. Вместо этого использует сложные алгоритмы, чтобы найти план выполнения, который имеет стоимость достаточно близко к минимуму возможная стоимость.

Оптимизатор запросов SQL Server делает не выбирайте только план выполнения с самой низкой стоимостью ресурса; Это выбирает план, который возвращает результаты пользователю с разумной стоимостью в ресурсы, и это возвращает результаты самый быстрый. Например, обработка запрос параллельно обычно использует больше ресурсы, чем обрабатывать его поочередно, но завершает запрос быстрее. Оптимизатор SQL Server будет использовать план параллельного выполнения вернуть результаты, если нагрузка на сервер будет не подвергаться неблагоприятному воздействию.

Оптимизатор запросов опирается на статистика распределения, когда это оценивает стоимость ресурсов разные методы извлечения информация из таблицы или индекса. Статистика распределения хранится для столбцы и индексы. Они указывают на Селективность значений в конкретный индекс или столбец. За Например, в таблице, представляющей автомобили, многие автомобили имеют одного производителя, но у каждого автомобиля есть свое транспортное средство идентификационный номер (VIN). Индекс на VIN является более избирательным, чем Индекс по производителю. Если статистика индекса не актуальна, Оптимизатор запросов не может быть лучшим Выбор текущего состояния Таблица. Для получения дополнительной информации о поддержание текущей статистики индекса, см. Использование статистики для улучшения запросов Производительность .

Answer 3

Я не могу говорить по всем системам СУБД, но Postgres специально использует расчетные размеры таблиц в рамках своих усилий по созданию планов запросов.Например, если таблица имеет две строки, она может выбрать последовательное сканирование таблицы для части JOIN, которая использует эту таблицу, тогда как, если у нее более 10000 строк, она может выбрать сканирование индекса или хеша (если либоиз них доступны.) Между прочим, раньше было возможно инициировать плохие планы запросов в Postgres, соединяя VIEWs вместо реальных таблиц, так как не было предполагаемых размеров для VIEW.

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

Answer 4

И схема, и данные.

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

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

Answer 5

Особенности Oracle:

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

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

• Ограничения внешнего ключа (могут использоваться для исключения таблиц)
• Секционирование (исключая целые диапазоны данных)
• Ограничения уникальности (например, уникальность индекса по сравнению со сканированием диапазона)
• Ограничения, не равные NULL (анти-объединения недоступны с not in () для столбцов, допускающих значение NULL)
• Типы данных (преобразования типов,специализированная арифметика дат)
• Материализованные представления (для переписывания запроса к агрегату)
• Иерархии измерений (для определения функциональных зависимостей)
• Проверка ограничений (ограничение вводится, если оноснижает стоимость)
• Типы индексов (b-дерево (?), растровое изображение, объединение, на основе функций)
• Порядок столбцов в индексе (a = 1 при {a, b} = сканировании диапазона,{b, a} = пропуск сканирования или FFS)

Ядро оценок основано на использовании статистики, собранной по фактическим данным (или обработанной). Статистика собирается по таблицам, столбцам, индексамs, разделы и, возможно, что-то еще.

Собирается следующая информация:

• Количество строк в таблице / разделе
• Средняя длина строки / столбца (важнодля расчета полного сканирования, хеш-соединений, сортировок, временных таблиц)
• Количество нулей в столбце (is_president = 'Y' в значительной степени уникально)
• Отдельные значения в столбце (last_name не оченьуникально)
• Мин. / макс. значение в столбце (помогает в условиях неограниченного диапазона, например date > x)

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

Кроме того, существует также физический порядок строк, который влияет нанасколько "хороший" или привлекательный индекс становится по сравнению с полным просмотром таблицы.Для индексов это называется «коэффициент кластеризации» и является мерой того, насколько порядок строк соответствует порядку записей индекса.

Answer 6

Для SQL Server существует множество факторов, которые влияют на окончательный план выполнения.На базовом уровне статистика играет очень большую роль, но она основана на данных, но не всегда на всех данных.Статистика тоже не всегда актуальна.При создании или перестройке индекса статистика должна основываться на полной / 100% выборке данных.Однако частота выборки для автоматического обновления статистики намного ниже, чем 100%, поэтому можно выбрать диапазон, который на самом деле не является представительным для большей части данных.Предполагаемое количество строк для операции также играет роль, которая может быть основана на количестве строк в таблице или статистике отфильтрованной операции.Таким образом, устаревшая (или неполная) статистика может привести к тому, что оптимизатор выберет неоптимальный план, так же как несколько строк в таблице могут привести к полному игнорированию индексов (что может быть более эффективным).

Как уже упоминалось в другом ответе, чем более уникальными (т.е. выборочными) данные будут, тем полезнее будет индекс.Но имейте в виду, что единственным гарантированным столбцом для статистики является начальный (или «самый левый» или «первый») столбец индекса.SQL Server может собирать и собирает статистику для других столбцов, даже если некоторые из них отсутствуют в каких-либо индексах, но только если установлена ​​опция DB AutoCreateStatistics (и это по умолчанию).

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

Но одна область, не рассматриваемая в вопросе, - это область самого запроса.У запроса, слегка измененного, но все же возвращающего те же результаты, может быть совершенно другой план выполнения.Также возможно сделать недействительным использование индекса, используя:

LIKE '%' + field

или упаковав поле в функцию, например:

WHERE DATEADD(DAY, -1, field) <  GETDATE()

Теперь, имейте в виду, что читатьоперации (в идеале) выполняются быстрее с индексами, но операции DML (INSERT, UPDATE и DELETE) выполняются медленнее (при этом требуется больше ресурсов ЦП и дискового ввода-вывода), поскольку индексы необходимо поддерживать.

Наконец, "оценочный"«ЦП и т. Д. Значения стоимости не всегда следует полагаться.Лучший тест - сделать:

SET STATISTICS IO ON
run query
SET STATISTICS IO OFF

и сосредоточиться на «логическом чтении».Если вы уменьшите логическое чтение, то вам следует повысить производительность.

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