Не пора ли убрать стоимость из плана запроса?
Erik Darling. Is It Time To Remove Costs From Query Plans?
Приглашенная звезда
Существует множество заблуждений относительно того, что означает стоимость (cost) в планах запросов. Часто при работе с клиентами сталкиваешься с тем, что все они переживают по поводу стоимости плана или стоимости оператора в плане.
Вот что я слышу постоянно:
Оптимизатор не знает, что у вас отличное хранилище. Предполагается, что это не так. Вы когда-нибудь видели, сколько стоит случайный ввод-вывод?
И неважно, сколько у вас памяти, или как много ваших данных уже находится в памяти; оптимизатор исходит из предположения, что данных в памяти нет (непрогретый кэш).
Стоимость может особенно ввести в заблуждение в предварительных/кэшированных планах, если виной тому прослушивание параметра.
Что касается меня, я, главным образом, использую стоимость для демонстрации того, почему SQL Server предпочитает один план другому. Как только вы осознаете, что оптимизатор выбирает планы на основе стоимости, легко сделать логический вывод, что другой вариант был оценен как более дорогой.
Другой момент состоит в том, что хотя многие метрики имеют «оценочные (предварительные)» и «фактические» компоненты, когда вы собираете фактический план выполнения...
только оценки
...ни одна из этих оценочных метрик стоимости не имеет фактических компонентов, которые появляются в фактических планах, и они не обновляются после выполнения запроса, чтобы отразить произошедшее, когда он выполнялся.
Если бы это было сделано, они оказались бы бесполезны для иллюстрации того единственного вывода, который они могут обоснованно сделать: почему был выбран этот план.
В последних версиях SQL Server и SSMS вы получаете время оператора.
Наряду с временем оператора мы получаем информацию о вводе/выводе, распределении строк/потоков в параллельных планах и набор других полезных метрик.
Я бы предпочел увидеть либо последнее время выполнения операторов, либо среднее время выполнения операторов в плане. Пока вы не назвали меня сумасшедшим, упомяну, что SQL Server 2019 имеет новое DMV - sys.dm_exec_query_plan_stats - которое отслеживает последний известный фактический план выполнения для запроса.
В долгосрочной перспективе имеет смысл заменить стоимость на время работы оператора. Это значительно упростит поиск худших частей планов запросов.
- Стоимость плана - это как долго выполняется запрос.
- Стоимость оператора - это процент времени, которое занимает выполнение оператора в пределах плана.
Оптимизатор не знает, что у вас отличное хранилище. Предполагается, что это не так. Вы когда-нибудь видели, сколько стоит случайный ввод-вывод?
И неважно, сколько у вас памяти, или как много ваших данных уже находится в памяти; оптимизатор исходит из предположения, что данных в памяти нет (непрогретый кэш).
Стоимость может особенно ввести в заблуждение в предварительных/кэшированных планах, если виной тому прослушивание параметра.
Чем полезна стоимость?
Что касается меня, я, главным образом, использую стоимость для демонстрации того, почему SQL Server предпочитает один план другому. Как только вы осознаете, что оптимизатор выбирает планы на основе стоимости, легко сделать логический вывод, что другой вариант был оценен как более дорогой.
Другой момент состоит в том, что хотя многие метрики имеют «оценочные (предварительные)» и «фактические» компоненты, когда вы собираете фактический план выполнения...
только оценки
...ни одна из этих оценочных метрик стоимости не имеет фактических компонентов, которые появляются в фактических планах, и они не обновляются после выполнения запроса, чтобы отразить произошедшее, когда он выполнялся.
Если бы это было сделано, они оказались бы бесполезны для иллюстрации того единственного вывода, который они могут обоснованно сделать: почему был выбран этот план.
Лучшие метрики
В последних версиях SQL Server и SSMS вы получаете время оператора.
Наряду с временем оператора мы получаем информацию о вводе/выводе, распределении строк/потоков в параллельных планах и набор других полезных метрик.
Я бы предпочел увидеть либо последнее время выполнения операторов, либо среднее время выполнения операторов в плане. Пока вы не назвали меня сумасшедшим, упомяну, что SQL Server 2019 имеет новое DMV - sys.dm_exec_query_plan_stats - которое отслеживает последний известный фактический план выполнения для запроса.
В долгосрочной перспективе имеет смысл заменить стоимость на время работы оператора. Это значительно упростит поиск худших частей планов запросов.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой