Знают ли оптимизаторы запросов к базе данных о различиях в производительности хранилища?

Насколько я понимаю, оптимизатор запросов в SQL Server (или любой другой СУБД, на самом деле) не знает о производительности хранилища под базой данных и будет принимать решения, как если бы все хранилище имело одинаковую стоимость. Это точно, или есть какие-то знания о производительности хранилища, которые принимаются во внимание?

В полностью надуманном примере предположим, что строки моей таблицы хранятся на SSD-диске в моей SAN с мгновенным временем доступа, где мои индексы хранятся на жестких дисках SAS, которые сильно перегружены, что приводит к насыщению диска и постоянным дисковым очередям. Когда СУБД генерирует план выполнения, больше ли предпочтение отдается сканированию таблицы, а не операции индекса (или, возможно, индексу сужения и связанным поискам таблицы, в отличие от индекса покрытия, потому что на дисках SAS меньше операций ввода-вывода)?

Я подозреваю, что ответ на этот вопрос твердый: «Не случайно, умный оптимизатор или даже знает о производительности диска», но я просто хотел посмотреть, знает ли кто-нибудь наверняка. Я использую SQL Server, но меня интересует любая система баз данных.

Оптимизатор запросов Sql-сервера не учитывает различия в производительности диска при составлении плана запроса. Пол Уайт (Paul White) дает отличный обзор оптимизатора на основе стоимости Sql Server здесь:

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

Некоторые ключевые моменты:

• Оптимизатор не пытается рассчитать точную стоимость плана. Он пытается выбрать план с относительно низкой стоимостью между несколькими альтернативами.

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

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

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

Вы можете использовать недокументированные вызовы dbcc, чтобы изменить некоторые предположения оптимизаторов запросов. НЕ ИСПОЛЬЗУЙТЕ ЭТО НА СЕРВЕРЕ ПРОДУКЦИИ

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

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

Еще одним моментом является то, что, хотя SQL не учитывает производительность ввода-вывода при составлении плана, он реагирует на производительность ввода-вывода во время выполнения плана (ограничение операций чтения с опережением при насыщении ввода-вывода и т. Д.)

Оптимизатор запросов Db2 for LUW знает характеристики производительности оборудования, на котором он работает, и принимает их во внимание.

В частности, каждое табличное пространство имеет два числовых параметра, которые отражают базовую производительность хранилища:, overheadкоторое отражает издержки контроллера ввода-вывода, время поиска и задержки диска в миллисекундах, и transferrateуказывает время, необходимое для передачи одной страницы табличного пространства с диска в память.

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

Параметры производительности ввода-вывода вместе с cpu_speedпараметром уровня менеджера баз данных используются оптимизатором для расчета затрат ввода-вывода и ЦП каждого оператора плана запроса и, следовательно, влияют на то, какой план в конечном итоге выбран. Впоследствии ваш сценарий будет полностью правдоподобным в Db2. Точно так же в системе с очень высокой скоростью ЦП и средней производительностью диска оптимизатор может предпочесть операторов с интенсивным использованием ЦП (например, сканирование таблиц плюс сортировка) более интенсивным операциям ввода-вывода (например, доступ к таблицам на основе индекса).

Я полагаю, что Db2 для z / OS также учитывает основные характеристики производительности оборудования, получая их на уровне управления хранением, а не как часть конфигурации базы данных.