Как заменить старые индексы и не сломать систему?

[minamoto]

Приятно, наверное, начать создавать такой индекс на таблице в 700 млн. строк и к концу обновления получить ошибку:

Msg 1946, Level 16, State 3, Line 23
Operation failed. The index entry of length 909 bytes for the index 'IX_ClientFile_StorageId_FolderId_FileStatus_FileName' exceeds the maximum length of 900 bytes.

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

В общем, даже если миграция у вас прошла успешно — вы уже приставили ружье к ноге и взвели курок. Осталось дождаться выстрела.

[KristinaMyLife]

Спасибо за замечание, хотя тип действительно NVARCHAR(900), к счастью ни одного файла с таким названием в системе нет, хотя все равно есть предупреждение при создании

Warning! The maximum key length is 900 bytes. The index 'IX_ClientFile_StorageId_FolderId_FileStatus_FileName' has maximum length of 1809 bytes. For some combination of large values, the insert/update operation will fail.

[Kant8]

Учитывая что FileName в индексе аж на 4 месте, и его влияние на распределение данных в индексе скорее всего будет уже очень маленьким, не лучше ли его просто добавить в инклюд?
Да, работать будет помедленней, тк будет скан листьев индекса (но как я писал, их скорее всего уже очень мало), но никаких падений после этого уже не может быть, а key lookup всё так же исчезнет.

[KristinaMyLife]

Вообще когда я бралась за этот проект я очень надеялась избавиться от поля FileName в индексе совсем, так как в некоторых запросах используются много полей таблицы и все равно возникает key lookup. К сожалению, при тестах обнаружили, что его отсутствие сказывается на производительности. Добавили в сам индекс исходя из того, что оно все таки кое-где используется в WHERE и оно было раньше в индексе. Возможно, вы правы и нужно было прогнать еще раз вариант с INCLUDE.