Почему вам следует прекратить смотреть на стоимость запроса
Пересказ статьи Erik Darling. Why You Should Stop Looking At Query Cost
Не жалейте расходов
За годы я получил множество запросов на получение sp_BlitzCache, чтобы отсортировать результаты по стоимости запроса. Я понимаю почему. Предполагается, что оптимизатор никогда не ошибается, и что стоимость непосредственно связана с плохой производительностью.
Также предпринимаются довольно ошибочные попытки определить параметры параллелизма на основе стоимости плана. Основная проблема заключается в том, что если у вас в данный момент имеется множество параллельных запросов, это означает лишь то, что предварительная стоимость последовательного плана была выше, чем ваше текущее пороговое значение стоимости для параллельного выполнения (Cost Threshold For Parallelism), и стоимость параллельного плана была меньше, чем стоимость последовательного плана.
Если вы увеличиваете Cost Threshold For Parallelism, то вполне можете получить параллельный план, поскольку последовательный план оказывается все еще более дорогим. Если вы, в конце концов, приведете Cost Threshold For Parallelism к точке, где некоторые запросы больше не будут считаться подходящими для параллельного выполнения, вас может не устроить производительность последовательной версии плана запроса.
Затем вы будете жаловаться на все те ожидания SOS_SCHEDULER_YIELD, которые получили.
Вместо того, чтобы смотреть предварительные метрики, лучше следить за тем, как фактически выполняются запросы. Для большинства серверов, за которыми я наблюдал, это означало отслеживать запросы с высоким средним временем ЦП и большим потреблением памяти. Эти метрики обычно представляют настраиваемые аспекты запроса.
В других случаях вы могли бы посмотреть на статистику ожиданий, чтобы указать тип запросов, к которым следует обратиться позже. Иногда ценными метриками являются чтения, запись и выполнения.
Опасность представляет наблюдать за итоговыми, а не за средними значениями, т.к. вы можете сосредоточиться на вещах, которые делают что-то понемногу много раз, и нет реального способа настроить ту небольшую активность, которую они генерируют, кроме как выполнять меньшее количество запросов.
В основном я смотрю на стоимость, чтобы понять выбор плана в рамках запроса, или когда сравниваются два различных плана для "одного и того же" запроса.
Именно здесь экспериментирование с подсказками по изменению форм плана и вариантов выбора может показать вам, почему вы получили именно тот план, который получили, и что вам, возможно, придется сделать, чтобы получить тот план, который вы ожидали получить.
Скажем, вы хотите выяснить, почему вы получили тот ли иной тип соединения. Вы используете хинт того типа соединения, которое хотите иметь, и появляется подсказка об отсутствующем индексе. Добавление индекса дает вам тот вид плана, который вы хотели, без использования хинта. И все жили долго и счастливо.
Пока индекс не стал фрагментированным.
Если вы увеличиваете Cost Threshold For Parallelism, то вполне можете получить параллельный план, поскольку последовательный план оказывается все еще более дорогим. Если вы, в конце концов, приведете Cost Threshold For Parallelism к точке, где некоторые запросы больше не будут считаться подходящими для параллельного выполнения, вас может не устроить производительность последовательной версии плана запроса.
Затем вы будете жаловаться на все те ожидания SOS_SCHEDULER_YIELD, которые получили.
Вместо этого
Вместо того, чтобы смотреть предварительные метрики, лучше следить за тем, как фактически выполняются запросы. Для большинства серверов, за которыми я наблюдал, это означало отслеживать запросы с высоким средним временем ЦП и большим потреблением памяти. Эти метрики обычно представляют настраиваемые аспекты запроса.
В других случаях вы могли бы посмотреть на статистику ожиданий, чтобы указать тип запросов, к которым следует обратиться позже. Иногда ценными метриками являются чтения, запись и выполнения.
Опасность представляет наблюдать за итоговыми, а не за средними значениями, т.к. вы можете сосредоточиться на вещах, которые делают что-то понемногу много раз, и нет реального способа настроить ту небольшую активность, которую они генерируют, кроме как выполнять меньшее количество запросов.
Для чего нужна стоимость?
В основном я смотрю на стоимость, чтобы понять выбор плана в рамках запроса, или когда сравниваются два различных плана для "одного и того же" запроса.
Именно здесь экспериментирование с подсказками по изменению форм плана и вариантов выбора может показать вам, почему вы получили именно тот план, который получили, и что вам, возможно, придется сделать, чтобы получить тот план, который вы ожидали получить.
Скажем, вы хотите выяснить, почему вы получили тот ли иной тип соединения. Вы используете хинт того типа соединения, которое хотите иметь, и появляется подсказка об отсутствующем индексе. Добавление индекса дает вам тот вид плана, который вы хотели, без использования хинта. И все жили долго и счастливо.
Пока индекс не стал фрагментированным.
Обратные ссылки
Нет обратных ссылок
Автор не разрешил комментировать эту запись
Комментарии
Показывать комментарии Как список | Древовидной структурой