Параметризация запросов. Ваш злейший враг?

добавлено: 28 окт 12
понравилось:0
просмотров: 2380
комментов: 3

теги:

Автор: SamMan

Вторая статья из цикла о параметризации запросов описывающая, соответственно, "проблемные места" данной технологии. Подробно разбираются сценарии и условия в которых параметризация наносит совершенно реальный и ощутимый вред системе вместо того, что бы быть нашим помощником в вопросах оптимизации запросов. Объясняется, почему в общем случае избежать подобных условий у нас не получится и приводятся четыре варианта по смягчению негативного влияния параметризации. Разбираются некоторые нюансы работы оптимизатора запросов и его взаимодействие с исполнителем запросов. Анализируется влияние такого взаимодействия на итоговый результат параметризации в тех или иных обстоятельствах, объясняются далеко не очевидные (а подчас и просто парадоксальные) побочные явления вытекающие из совместной работы двух указанных компонентов SQL Server. Уровень материала - 300.


Перейти к статье.

Комментарии


  • Вот тоже встали на похожие грабли с 1С. В цикле выполняется запрос с разыми параметрами.
    "Селективность одного значения в колонке фильтрации резко отличается".
    1C "оборачивает" запросы в структуры вида: "sp_executesql" Пока нет идей как в такой ситуации избавляться от parameter sniffing. Ну разве что в том же цикле ставить "sp_reompile".

  • Да, вполне вариант для достижения вашей цели. Например, с помощью план-гайдов(см. статью) "навешивать" на проблемный запрос принудительную опцию OPTION (RECOMPILE). Каждое выполнение запроса будет рассматриваться (оптимизатором) совершенно независимо от факта предыдущих исполнений его же.

  • SamMan, запрос написан на языке 1С. В t-sql его переводит сама 1с-ка. Да, видимо, единственный более менее красивый вариант, переписать этот же запрос на t-sql.

    ps: Спасибо за статью. Отличные примеры, всё очень здорово, просто и понятно расписано.



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