Предположим, что в SQL Server у меня есть очень большая таблица (столбцы от A до Z), которая имеет КЛАСТЕРНЫЙ ПЕРВИЧНЫЙ КЛЮЧ на A и УНИКАЛЬНЫЙ НЕКЛАСТЕРНЫЙ индекс IX1 по столбцам B, C, D, включая E, F, G. Затем мне нужно покрыть другой запрос новым НЕКЛАСТЕРИРОВАННЫМ индексом IX2 по D, C, B, включая J, K, M.
Поскольку IX1 уже обеспечивает уникальность для B, C, D, имеет ли смысл также создавать IX2 UNIQUE? Есть ли серьезные плюсы и минусы.
Если ваш индекс уникален, сообщите SQL, что он уникален. Оптимизатор может использовать дополнительную информацию, нет никаких недостатков в том, чтобы сделать ее такой.
Тем не менее, вам действительно нужен второй индекс? Можно ли использовать другой порядок ключей для некоторых других запросов? Если нет, почему бы просто не добавить дополнительные включаемые столбцы в первый индекс, это, вероятно, будет дешевле в долгосрочной перспективе.
Я не уверен, как будет развиваться конкретный сценарий, но вы сможете его протестировать без особых проблем.
В среде разработки (если она существует) попробуйте выполнить запросы с обоими сценариями и проверьте планы выполнения. Если второй индекс предотвращает такие вещи, как сканирование таблиц, велика вероятность, что оно того стоит. Если вы обнаружите, что первый индекс действительно выполняет всю работу, вероятно, это не так.
Когда дело доходит до индексов, я не вижу серьезных недостатков помимо обычных вещей. Если вы начнете добавлять слишком много, ваши вставки, обновления и удаления могут начать замедляться, а также занять больше места на диске.