Производительность между некластеризованным индексом и составным первичным ключом

Question

Я изменяю первичный ключ базы данных SQL Server 2014 из составного ключа, содержащего столбцы следующих типов:

VARCHAR(10), INT, DATETIME

к составному ключу, содержащему

INT, DATETIME

, где INT во втором ключе - это новый столбец, хэш предыдущей комбинации VARCHAR(10), INT. Я пока не могу изменить первичный ключ, поэтому после добавления нового столбца я создал индекс, который в будущем будет новым первичным ключом (INT, DATETIME):

CREATE UNIQUE NONCLUSTERED INDEX MyIndex 
     ON MyTable(MyIdCol, MyDateCol)

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

В этот момент я экспериментировал с созданием (INT, DATETIME) нового первичного ключа. Скорость запросов улучшилась на 30-40%, но я честно думал, что было бы намного быстрее запрашивать этот новый первичный ключ, чем старый, который имеет VARCHAR (конечно, я мог что-то испортить в своих тестах - схема БД довольно сложна и занимает 24 часа для настройки тестовых случаев).

К сожалению, я просто отбрасываю первичный ключ в производственном процессе - мне нужна фаза, когда у меня есть старый первичный ключ и новый уникальный индекс одновременно, поэтому мне нужно будет добиться аналогичной производительности при поисках по этому индексу. Мне нужно направление на что посмотреть. Если честно, я не до конца понимаю, почему запросы к INT,DATETIME даже просто как индекс, а не первичный ключ, намного медленнее, чем VARCHAR,INT,DATETIME первичный ключ.

Answer 1

Это слишком долго для комментария.

Насколько медленнее "медленнее"?При поиске в некластеризованном индексе ядру базы данных необходимо найти ссылки на строки в индексе (довольно быстро), а затем загрузить страницы данных для извлечения строки.

При поиске с использованием кластерного индексанет необходимости загружать страницы данных.

Различие, вероятно, будет гораздо более заметным при извлечении нескольких строк, поскольку кластеризованный индекс будет иметь данные на тех же страницах данных.Некластеризованный индекс, вероятно, будет извлекаться с отдельной страницы для каждого извлекаемого элемента (до определенного момента).

Вы можете сравнить разницу в производительности, выбрав только столбцы в индексе.Это может быть не то, что вы хотите, но это жизнеспособное сравнение производительности.Они должны быть похожи между двумя индексами.

Это может объяснить разницу в производительности.Если это так, то это не о чем беспокоиться, потому что это ожидаемые издержки, когда не используется кластерный индекс.В общем, это относительно много для быстрых запросов и менее важно для медленных запросов.