SQL Server - оптимизация неуникального кластерного индекса

Question

Мы переносим существующее настольное приложение компании в облако. Я выполнял большую часть работы с базами данных и оптимизировал их для соответствующих индексов, чтобы поддерживать оперативность по мере необходимости.

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

У меня есть 2 таблицы проблем, которые определенно будут составлять большую часть трафика, но проблема та же. Мы ожидаем от миллионов до десятков миллионов записей в нашей таблице пользовательских настроек. Наше устаревшее программное обеспечение, которое я подтвердил, будет синхронизировать ~ 1300-1500 опций конфигурации на пользователя в базу данных. Ожидайте размер таблицы не менее ~ 40-50 миллионов строк.

Мой первоначальный дизайн стола был таким

    CREATE TABLE dbo.Settings
    (
       SettingID BIGINT PRIMARY KEY NOT NULL IDENTITY(1,1),
       CustomerID INT NOT NULL,
       SettingTypeID INT NOT NULL
       .... other rows
    )

CREATE NONCLUSTERED INDEX [INDEX_NAME] ON dbo.Settings(CustomerID);

Я думаю, что лучшая оптимизация -

CREATE TABLE dbo.Settings
(
   CustomerID INT NOT NULL,
   SettingTypeID INT NOT NULL,
   .... other rows
)

CREATE CLUSTERED INDEX [INDEX_NAME] ON dbo.TRSettings(CustomerID);

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

SELECT * FROM dbo.Settings WHERE CustomerID=@CustomerID ...

При профилировании выборка кажется в 5-50 раз быстрее, в среднем примерно в 25-30 раз быстрее. Поскольку он может выполнять сканирование диапазона, а не повторные поиски из некластеризованного индекса.

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

Доводим до сведения нашего продукта, и текущий консенсус, по-видимому, заключается в том, что «мы добавим больше оборудования, если потребуется», поскольку нам пришлось бы потратить около половины дня на переписывание некоторого кода для работы (довольно позитивная новая таблица не работает со структурой сущностей или вы можете получить доступ к скрытому столбцу uniquifier?), но, насколько мне известно, есть какие-то ошибки, о которых я не знаю? Похоже, что для записей о клиентах, где вы часто будете индексировать несколько номеров элементов (то есть пользовательских настроек), лучше всего иметь такой индекс, который приближается к кластеризации NoSQL, чтобы вы могли гарантировать локальность диска. Я просто недостаточно знаком с производительностью вставки, чтобы понять, не возникнут ли непредвиденные проблемы с перестройкой дерева.