Изменение поля кластерного индекса MSSQL с "случайных" GUID на последовательные GUID - как это повлияет на индексы
У нас есть база данных MSSQL, в которой все первичные ключи являются GUID (уникальными идентификаторами). GUID создаются на клиенте (в C#), и мы рассматриваем возможность изменения клиента для генерации последовательных (гребенчатых) GUID, а не просто использования Guid.NewGuid(), чтобы повысить производительность базы данных.
Если мы сделаем это, как это повлияет на установки, в которых уже есть данные со "случайными" GUID в качестве кластерных ПК? Можно ли что-нибудь сделать (кроме изменения всех значений PK), чтобы перестроить индексы, чтобы избежать дальнейшей фрагментации и плохой производительности вставки?
Пожалуйста, дайте четкие и подробные ответы, если можете; Я - разработчик C# в глубине души и не слишком хорошо знаком со всеми тонкостями SQL Server.
Спасибо!
1 ответ
Быстрый комментарий: GUID + кластерный индекс? Это звучит плохо - кластеризованный индекс означает, что таблица физически находится на диске в порядке индекса - поэтому вставка должна потенциально переписать страницы базы данных, чтобы они были в порядке. Измените это на некластеризованный индекс, и производительность улучшится.
У последовательных GUID есть много проблем, они действительно не гарантируются уникальными, если они последовательные, где-то, если вы масштабируете фрагмент для выполнения в нескольких местах, последовательность потенциально дублируется.
Попробуйте отбросить свой кластеризованный индекс и создать тот же самый некластеризованный индекс. Вы почти наверняка исправите все проблемы. Случайный GUID НЕ является проблемой производительности, Guid.NewGuid не занимает много времени (МНОГИЕ другие вещи будут замедляться до того, как эта подпрограмма станет проблемой).).
Кластерные индексы не идеальны для всего.