У меня есть таблица с большим количеством строк (10K +), а ее первичный ключ - GUID. Первичный ключ сгруппирован. В этой таблице производительность запросов довольно низкая. Пожалуйста, предоставьте предложения, чтобы сделать его эффективным.Улучшение производительности первичного ключа GUID индекса кластера
Вы должны использовать NEWSEQUENTIALID() вместо того, чтобы увидеть здесь Some Simple Code To Show The Difference Between Newid And Newsequentialid
Я много читал о newsequentialid(), но кажется, что это функция SQL. Может ли кто-нибудь сказать мне, что делать, если Guid генерируется из кода (C#). –
-1 Каким образом этот ответ связан с физической кластеризацией индексов? Человек, задающий вопрос, уже заявил, что у него 10K + строк, и он, вероятно, не хочет идти и менять все ключи. – nashwan
Вы можете попробовать последовательные GUID, которые сделают индекс более эффективным. Информация here.
Сгруппированный указатель на GUID не является хорошим дизайном. Сама природа GUID заключается в том, что она случайна, а кластерный индекс физически заказывает записи по ключу. Две вещи полностью противоречат друг другу. Для каждой вставки SQL необходимо изменить порядок записей на диске! Удалите кластеризацию из этого индекса!
Время использования кластеризации - это когда у вас есть «естественный» порядок данных: время вставлено, номер счета и т. Д. Для полей времени кластеризация почти бесплатна. Для номера счета он может быть бесплатным или дешевым (когда номера счетов назначаются последовательно).
Хотя технические проблемы вокруг проблемы с GUID могут быть техническими, лучше всего понять, когда использовать кластеризацию.
+1 для резкого тона. В этом вопросе не так много серой области. Не делай этого. – Droogans
Пожалуйста, во избежание создания кластерного индекса для lenghty строк столбцов. GUID будет содержать 36 символов. Это уменьшит производительность запроса, даже если вы создали кластерный индекс. для лучшей практики используйте целые столбцы идентификаторов.
Руководство - 16 байт - не 36 символов. –
целое число не является хорошим дизайном для больших баз данных. – Leonardo
Кимберли Трипп очень хорошо обсуждает эту проблему для больших таблиц на своем сайте по этой ссылке: [GUIDs как ОСНОВНЫЕ КЛЮЧИ и/или кластерный ключ] (http://www.sqlskills.com /BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx). – Graeme
Вам необходимо проанализировать ваш запрос. Мы можем только догадываться, почему ваши запросы работают плохо, не просматривая план выполнения (который вы можете легко успокоить с SQL Server или Oracle).
Учитывая, что идентификатор GUID является 128-битным значением (если он хранится необработанным), GUID сокращает плотность блоков данных и индексов на целых 50% (в случае индекса первичного ключа), поэтому убедитесь, что GUID подходит.
Но это может и не быть проблемой, поэтому просмотрите план запроса. Это может быть несколько других вопросов.
Нет проблем с использованием GUID в качестве первичного ключа. Просто убедитесь, что когда вы на самом деле устанавливаете GUID в качестве первичного ключа, установите индекс, который он автоматически создает, чтобы иметь тип Non-clustered. Многие люди забывают (или не знают) сделать это в SQL Server.
НИКОГДА не используйте кластерный указатель для GUID. Это приведет к физическому упорядочению вокруг GUID на диске, что, очевидно, бессмысленно (как уже указывали другие)
НИКОГДА не используйте кластерный индекс для GUID? Это смелое заявление. Вы уверены, что нет встречных примеров? – MarkPflug
Назовите один, если вы знаете один :-). Я не вижу причин, по которым вы хотели бы физически заказать что-то вокруг GUID. – nashwan
Если производительность SELECT важна, и вы будете ВЫБРАТЬ на GUID ... –
Возможный дубликат [Каковы наилучшие методы использования GUID в качестве первичного ключа, особенно в отношении производительности?] (http://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega) – AHiggins
Сделать это не сгруппированным! (если он должен оставаться GUID) – nashwan