Оконные функции и row goal

добавлено: 10 дек 13
понравилось:0
просмотров: 1899
комментов: 2

теги:

Автор: SomewhereSomehow

Картинка с другого сайта.
В этой заметке, я хочу описать один любопытный случай падения производительности в запросах с оконными функциями и неравномерным распределением данных. Для людей, работающих с SQL Server, использование оконных функций, как и неравномерное распределение данных – обычное и довольно частое явление, с которым периодически сталкиваешься в реальной жизни. При определенном стечении обстоятельств, два фактора соединенных вместе, могут стать источником низкой производительности.
Читать дальше

Комментарии


  • Хорошая статья. У нас на проекте возникают сложности с оптимизацией некоторых запросов. Можно ли как-то посмотреть не ожидаемую стоимость операции, а фактическую? Бывает смотришь план выполнения, а там не видно узких мест, а выполняется долго. И еще почему, при создании представления с индексами, всегда приходится заставлять SQL Server использовать эти индексы? Хотя в очень простых случаях он бывает даже сам использует индекс представления хотя и представления в запросе нет.

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

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

    Также стоит обратить внимание на само количество строк. Большое число передаваемых строк (в SSMS на это указывают жирные стрелки между операторами) может свидетельствовать о том что не хватает каких либо индексов и оптимизатор вынужден сканировать и обрабатывать большую порцию данных. Если при этом еще присутствуют операторы потребляющие память (например, Sort, Hash Match и т.д.), то ситуация может усугубиться за счет слива данных в tempdb (spill).

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

    Далее, в процессе оптимизации, оптимизатор основываясь на стоимости ищет варианты один из которых, сопоставить запрос с существующим представлением.

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

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



Необходимо войти на сайт, чтобы оставлять комментарии