подскажите почему у некоторых объектов используется два индекса один из них первичный ключ и некластеризованный, а второй кластеризованный, но не первичный?
Таких объектов в базе 92 штуки:
Почему в этих объектах не используется один кластерный индекс? Как безболезненно можно их изменить и не сломать базу?
понятно что добавление нового проще, но не согласен, что оно решает проблему. Почему выбрали не замену первичного ключа на кластеризованный? Так при вставке нужно добавлять записи в 2 индекса вместо одного, что наоборот усложняет работу.
Ранее мы проводили исследования блокировок (long-lock) и пришли к решению использования повсеместно во всех таблицах кластерных индексов в качестве первичных констрейнтов. Но если в таблице присутствуют blob-колонки, то лучшим для производительности будет решение использовать некластеризированный первичный констрейнт с внешним кластеризированным индексом по первичному ключу. Например, как в таблице Account.
Мы настоятельно не рекомендуем изменять эти индексы в базовых таблицах для сохранения корректной работу базовых механизмов. Однако индексы в пользовательских таблицах вы можете изменять.
1) "Почему в этих объектах не используется один кластерный индекс? Как безболезненно можно их изменить и не сломать базу?" - в определенный момент создали дополнительный кластерный ключ для ряда таблиц для избежание блокировок при определенных операциях. Убирать или изменять их не стоит, в таком случае мы не гарантируем корректность работы системы.
2) "Почему выбрали не замену первичного ключа на кластеризованный? Так при вставке нужно добавлять записи в 2 индекса вместо одного, что наоборот усложняет работу." - да, но это не только замедляет но и помогает. Именно такой набор индексов и выбор первичного ключа показали наилучший результат в среднем по всем кейсам.
