Порядок некластеризованного индекса в условии условия - PullRequest
0 голосов
/ 20 сентября 2019

Предположим, что есть таблица с первичным ключом colD и некластеризованным индексом (colA, colB, colC), и поэтому ее порядок такой.

Имеет ли значение, в каком месте находятся данные при выборе данных в этой таблице?

Например:

SELECT * 
FROM table
WHERE colA = A AND colB = B AND colC = C

SELECT * 
FROM table
WHERE colB = B AND colA = A AND colC = C

Есть ли разница в эффективности?

Я пробовал их на данных 1000 КБ, план выполнения кажется почти таким же.Как я могу объяснить это явление?

Ответы [ 2 ]

1 голос
/ 20 сентября 2019

Ответ - нет.Когда он создает план запроса, SQL Server принимает решение о том, какие предикаты использовать первым и последним.Он будет смотреть на статистику данных (т. Е. Он часто уже имеет представление о том, сколько строк будет соответствовать каждому из ваших значений предиката), и он смотрит на доступные индексы, с которыми он может работать.

порядок написания предикатов не имеет никакого значения.

То же самое относится и к таблицам.Он выбирает порядок соединения.Единственная ситуация, когда это меняется, если вы включаете OPTION (FORCEORDER) и говорите ему, что знаете лучше, чем он.Это очень редко хорошая идея.Обычно это происходит, когда вы знаете что-то, чего он не знает, или если в продукте есть ошибка (также очень редкая для такого рода вещей).

0 голосов
/ 20 сентября 2019

Вы говорите, что видите здесь постоянную и предсказуемую разницу?Если так, то я был бы искренне удивлен.

В таком запросе оптимизатор примет и испортит ваш код по своему усмотрению - я ожидаю нулевую разницу из-за упорядочения логических тавтологий в предложении where!

MyСуть в том, что если вы видите здесь различия в производительности, они случайны и отражают типичные приливы и отливы вашей операционной системы и доступные ресурсы (и, конечно, разногласия с другими приложениями / пользователями SQL).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...