Повышение производительности первичного ключа GUID индекса кластера

Question

У меня есть таблица с большим количеством строк (10K +), и ее первичный ключ - GUID. Первичный ключ кластеризован. Производительность запросов в этой таблице довольно низкая. Пожалуйста, предоставьте предложения, чтобы сделать его эффективным.

Answer 1

Кластерный индекс по GUID не очень хороший дизайн. Сама природа GUID заключается в том, что он случайный, а кластерный индекс физически упорядочивает записи по ключу. Две вещи полностью расходятся. Для каждой вставки SQL должен переупорядочивать записи на диске! Удалить кластеризацию из этого индекса!

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

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

Answer 2

Нет проблем с использованием GUID в качестве первичного ключа. Просто убедитесь, что когда вы на самом деле устанавливаете GUID в качестве первичного ключа, тогда установите автоматически созданный индекс типа Некластеризованный. Многие люди забывают (или не знают) сделать это в SQL Server.

НИКОГДА не используйте кластерный индекс по GUID. Это приведет к физическому упорядочению вокруг GUID на диске, что, очевидно, бессмысленно (как уже отмечали другие)

Answer 3

Вам нужно использовать newsequentialid () вместо этого, см. Здесь Простой код, чтобы показать разницу между Newid и Newsequentialid

Answer 4

Вы можете попробовать последовательные GUIDS, которые сделают индекс более эффективным. Информация здесь .

Answer 5

Вам нужно проанализировать ваш запрос. Мы можем только догадываться, почему ваши запросы работают плохо, не просматривая план выполнения (который вы можете легко получить из SQL Server или Oracle).

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

Но это может и не быть проблемой, поэтому просмотрите план запроса. Это может быть несколько других проблем.

Answer 6

Пожалуйста, избегайте создания кластеризованного индекса для длинных строковых столбцов. GUID будет иметь 36 символов. Это снизит производительность запросов, даже если вы создали кластерный индекс. для лучшей практики используйте целочисленные столбцы идентификаторов.