Показать сообщение отдельно
Старый 19.10.2007, 14:00   #52  
Голышев Михаил is offline
Голышев Михаил
Участник
 
106 / 10 (1) +
Регистрация: 03.07.2006
Цитата:
Сообщение от MSI Посмотреть сообщение
И для каждого из таких запросов, как я понял, надо приципить свой план. Геморройно... Или надо что-то не так делать? Может мы не так лечим и надо действительно сделать обновление статистики и сиквель должен начать правильно выстраивать планы выполнения? Или можно как-то назначить план на группу запросов?
Если вы испльзуете Plan Guide - то для каждого запроса свой хинт. (у нас их около 500 на одну БД)

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

При открытии же форм, как раз идут запросы с > >= < и <=.
Например при фильтрации финансовых операций по счету будет запрос:
Код:
exec sp_executesql N'SELECT  * FROM "dbo"."КРОК$G_L_Entry" WHERE (("G_L_Account_No_"=@P1)) 
AND  "Entry_No_">=@P2 ORDER BY "Entry_No_" OPTION (FAST 10)',
N'@P1 varchar(20),@P2 int','61100100',4
При этом план строится 1 раз, компилируется и будет использован для параметризированного запроса при любых параметрах.

Очевидно, что если в качестве @P2 первый раз было передано большое число, то план будет построен по кластерному индексу. (Если @P2 маленькое, то план будет правильный - состоять из джоина Index Seek по G_L_Account и Clustered Index Seek)
И в дальнейшем, этот план по кластерному индексу будет использован и для маленьких @P2, что будет приводить к сканированию всей таблицы.

Эти случаи надо фиксить Plan Guide'ами