Исключение поиска кластеризованного индекса SQL, вложенного в необязательное внешнее применение - PullRequest
Новая
       30

Исключение поиска кластеризованного индекса SQL, вложенного в необязательное внешнее применение

1 голос
/ 12 мая 2011

Я использую SQL Server 2008. Я создал большой поисковый запрос (содержащийся в определенной пользователем функции) со многими необязательными параметрами.Упрощенная версия результата выглядит примерно так: 

Declare @optionalSubTableParameter as userDefinedTableType READONLY

select id
from table t

--here is optional parameter 1 (there are quite a few of these)
outer apply(
 select top (1) st.item
 from subTable st
 inner join @optionalSubTableParameter ostp
 on (ostp.value = st.item or ostp.value is null)
 where st.index = t.index 
 and ostp.value is not null
 -- also tried: (select top(1) * from @optionalSubTableParameter) is not null
)someParam

where (someParam.item is not null 
or (select top(1) * from @optionalSubTableParameter) is null)

Итак, проблема заключается в плане выполнения, я, кажется, трачу время на:

поиск кластеризованного индекса (кластеризовано)

[subTable]. [IX_subTableIndex ..

Стоимость: 8%

Я знаю 8% не много, но это повторяется 6 раз (и скоро будет еще несколько), так что это уже 48% моего времени выполнения.

Я думал, что проверка (@optionalSubTableParameter не являетсяnull) в пределах внешнего применения, я бы избегал вычислений, таких как поиск кластеризованного индекса по ненужной таблице (если не указан параметр).Если кто-нибудь может помочь объяснить, есть ли способ для меня избежать этого вычисления, это было бы здорово!

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

Я прошу прощения, если есть какие-либо повторяющиеся сообщения, но мне не повезло найти ответ самостоятельно.

1 Ответ

3 голосов
/ 12 мая 2011

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

Во-вторых, вы все еще выполняете поиск по индексу из-за этой строки:

where st.index = t.index

Вы МОЖЕТЕ быть в состоянии устранить это, изменив порядок предложения WHERE в этом внешнем применении, но я бы не стал рассчитывать на это.

Так как это AND Я думаю, что он может оценить оба компонента. Кто-то еще мог бы обратиться, если это короткие замыкания или нет.

...