У меня есть таблица с большим количеством строк (10K +), а первичный ключ - GUID. Первичный ключ сгруппирован. В этой таблице производительность запросов довольно низкая. Пожалуйста, предоставьте предложения, чтобы сделать его эффективным.
Улучшение производительности первичного ключа GUID индекса кластера
Ответ 1
Вам нужно использовать newsequentialid(), а не здесь Простой код, чтобы показать разницу между Newid и Newsequentialid
Ответ 2
Кластеризованный индекс по GUID не является хорошим дизайном. Сама природа GUID заключается в том, что он случайный, а кластерный индекс физически упорядочивает записи по ключу. Две вещи полностью противоречат друг другу. Для каждой вставки SQL необходимо изменить порядок записей на диске! Удалите кластеризацию из этого индекса!
Время использования кластеризации - это когда у вас есть "естественный" порядок данных: введенное время, номер учетной записи и т.д. Для полей времени кластеризация почти бесплатна. Для номера счета он может быть бесплатным или дешевым (когда номера счетов назначаются последовательно).
Хотя проблемы с GUID могут быть техническими, лучшая идея заключается в том, чтобы понять, когда использовать кластеризацию.
Ответ 3
Нет проблем с использованием GUID в качестве первичного ключа. Просто убедитесь, что когда вы на самом деле устанавливаете GUID в качестве первичного ключа, установите индекс, который он автоматически создает, чтобы иметь тип Non-clustered. Многие люди забывают (или не знают) сделать это в SQL Server.
НИКОГДА не используйте кластерный индекс для GUID. Это приведет к физическому упорядочению вокруг GUID на диске, что, очевидно, бессмысленно (как уже указывали другие)
Ответ 4
Вы можете попробовать последовательные GUID, которые сделают индекс более эффективным. Info здесь.
Ответ 5
Вам нужно проанализировать ваш запрос. Мы можем только догадываться, почему ваши запросы работают плохо, не просматривая план выполнения (с которым вы легко справляетесь с SQL Server или Oracle).
Учитывая, что GUID является 128-битным значением (если он хранится необработанным), GUID сокращает плотность блоков данных и индексов на целых 50% (в случае индекса первичного ключа), поэтому убедитесь, что GUID подходит.
Но это может и не быть проблемой, поэтому просмотрите план запроса. Это может быть несколько других проблем.
Ответ 6
Пожалуйста, избегайте создания кластерного индекса для столбцов строки длины. GUID будет иметь 36 char. Это уменьшит производительность запроса, даже если вы создали кластерный индекс. для лучшей практики используйте целые столбцы идентификаторов.