Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Оптимизация запроса.  [new]
SergeiGer
Member

Откуда:
Сообщений: 8
 		Для начала чисто теоретический вопрос. У меня запрос типа SELECT * FROM Table CROSS APPLY Function(Table.ID) выполняется на ПОРЯДОК БЫСТРЕЕ !! Чем тот же, но с выборкой конкретного поля - SELECT Table.ID FROM Table CROSS APPLY Function(Table.ID) .
Я специально пока не выкладываю описания реальной ситуации, так как в принципе не понимаю как вывод всех полей может быть МЕДЛЕННЕЙ чем одного поля??
9 окт 13, 14:33    [14945013]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
aleks2
Guest 		Что-то аффтор бредит...
9 окт 13, 14:35    [14945030]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
kalimba
Member

Откуда:
Сообщений: 297
 		SergeiGer,

Чтобы точно замерить производительность надо перед выполнением делать (не на продакшене разумеется)
DBCC FREEPROCCACHE
GO
CHECKPOINT
GO
DBCC DROPCLEANBUFFERS

Если у вас и после этого будет быстрее выполнятся - прилагайте планы запросов и SET STATISTICS TIME ON.
9 окт 13, 14:43    [14945118]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
SergeiGer
Member

Откуда:
Сообщений: 8
 		Запрос SELECT * FROM OrderDevice od
INNER JOIN ItemProfile ip ON ip.ItemProfileId = od.ItemProfileId
CROSS APPLY dbo.fn_BuildItemList(ip.ArticleItemId, 'ItemRelation', GetDate(), 0)f
INNER JOIN ItemProfile ip1 ON ip1.ArticleItemId = f.AID
WHERE OD.OrderId = 63857 AND ip.ArticleItemId <> f.AID
выполнялся 3 миллисекунды и вызвал 1501 операций чтения,
а запрос
SELECT ip.ArticleItemId
FROM OrderDevice od
INNER JOIN ItemProfile ip ON ip.ItemProfileId = od.ItemProfileId
CROSS APPLY dbo.fn_BuildItemList(ip.ArticleItemId, 'ItemRelation', GetDate(), 0)f
INNER JOIN ItemProfile ip1 ON ip1.ArticleItemId = f.AID
WHERE OD.OrderId = 63857 AND ip.ArticleItemId <> f.AID
выполнялся 11 секунд и вызвал 10773514 операций чтения

К сообщению приложен файл. Размер - 123Kb
9 окт 13, 14:53    [14945226]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
SergeiGer
Member

Откуда:
Сообщений: 8
 		Запрос
SELECT * FROM OrderDevice od
INNER JOIN ItemProfile ip ON ip.ItemProfileId = od.ItemProfileId
CROSS APPLY dbo.fn_BuildItemList(ip.ArticleItemId, 'ItemRelation', GetDate(), 0)f
INNER JOIN ItemProfile ip1 ON ip1.ArticleItemId = f.AID
WHERE OD.OrderId = 63857 AND ip.ArticleItemId <> f.AID

К сообщению приложен файл. Размер - 75Kb
9 окт 13, 14:58    [14945282]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
aleks2
Guest 		Ну, теперь аффтору осталось научиться получать и читать планы исполнения... и озарение наступит.
9 окт 13, 15:09    [14945401]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
Glory
Member

Откуда:
Сообщений: 104751
SergeiGer
так как в принципе не понимаю как вывод всех полей может быть МЕДЛЕННЕЙ чем одного поля??

Потому что вывод полей - это последняя операция при выполнении запроса.
А до этого серверу нужно много еще чего сделать
9 окт 13, 15:12    [14945430]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
Crimean
Member

Откуда:
Сообщений: 13147
aleks2
Что-то аффтор бредит...


отнюдь. указание * толкает оптимизатор таки взять кластерный индекс. а указание поля толкает взять плохенький, но покрывающий. результат мы видим. планы, действительно, разные и они, безусловно, все объясняют
и - да - не знаю как другие, а я этим поведением вовсю пользуюсь для получения личной выгоды чтобы получить нужный мне план и получить его достаточно стабильно
9 окт 13, 15:55    [14945855]     Ответить | Цитировать Сообщить модератору
 Re: Оптимизация запроса.  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
 		SergeiGer,

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

У вас видимо, обратная ситуация. Когда скан оказывается выгоднее. На правах телепатии могу только предполагать, что для медленного запроса строится план с поиском по индексу и соединением Nested Loops в котором на внутренней или внешней стороне присутствует сильная недооценка (возможно, вызваная функцией, если она не inline или чем-то еще).

Смотрите планы, выкладывайте их сюда файлами если сами затрудняетесь.

А я пошел на юзер-группу, буду докалдывать про Columnstore Index 2014 /реклама детектед/ =)
9 окт 13, 15:59    [14945887]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить