Поиск таблицы Guid быстрее, когда Guid является кластеризованным индексом?

Question

Если я собираюсь запрашивать таблицу Гидами (независимо от проблем с фрагментацией с Гидами), было бы быстрее иметь Guid как кластерный индекс, а не некластеризованный индекс или вообще не индекс?

Этот вопрос исходит с точки зрения только для чтения. Мне просто интересно, будет ли улучшение скорости между поисковыми строками для конкретного Guid и будет ли поиск быстрее быстрее с индексом или без индекса или с кластеризованным индексом?

В качестве альтернативы, я вполне уверен в ответе на мой следующий вопрос, но теперь применим идентификаторы int к предыдущему вопросу. Будет ли быстрее искать, если таблица кластеризована этим int? (Это, а не сгруппировано по какому-либо другому элементу в таблице?)

Я знаю, что есть много других вопросов, размещаемых на эту тему, но я не нашел конкретный ответ, что я ищу в любом из них:
Should a Sequential Guid primary key column be a clustered index?
Improving performance of cluster index GUID primary key
Clustered primary key on unique identifier ID column in SQL Server
uniqueidentifier with index
Should I get rid of clustered indexes on Guid columns

Спасибо за любую помощь!

Answer 1

Предполагая, что MS SQL Server. Это может быть или не относится к другим СУБД:

Если у вас есть кластерный индекс, то он будет самым быстрым, хотя, если вы ищете одну строку, разница между этим и некластеризованным индексом будет незначительной , Когда вы используете некластеризованный индекс, серверу необходимо сначала найти нужное значение в индексе, а затем выполнить выборку полной записи из хранилища таблиц. Хранилище таблиц - это кластеризованный индекс, поэтому поиск по кластерному индексу устраняет этот шаг (называемый поиском закладок), но этот шаг почти незаметен для одной строки.

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

Наличие некластеризованного индекса в INT (при прочих равных условиях) будет немного быстрее, чем использование GUID, поскольку сам индекс будет меньше (поскольку INTs намного меньше GUID), что означает, что сервер имеет чтобы пройти меньше страниц, чтобы найти значение, которое оно хочет получить.В случае с кластеризованным индексом я не думаю, что вы увидите большую часть разницы, если размеры строк уже велики по сравнению с разницей между GUID и INT, но я не тестировал это.

Answer 2

Таблица, безусловно, будет запрашивать быстрее с помощью кластеризованных индексов Integer, чем индексы GUID. Причина - размер типа данных.

Если вы уже решили пойти с GUID в качестве ключа, то, вероятно, сгенерируйте эти GUID с помощью newSequentialId() вместо NewId(), поскольку это уменьшит эффект фрагментации в указателях Guid, поскольку идентификаторы всегда будут увеличиваться, и у вас меньше шансы на разделение страницы.

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

Answer 3

Как уже упоминалось, поиск по кластерному индексу для одного элемента будет всегда быстрее. Это связано с тем, что кластеризованный индекс - это сами данные, и никакие поисковые запросы не требуются после того, как вы нашли свой индексный элемент.

Главным преимуществом кластерного индекса является возможность извлекать «диапазоны» данных (например, «на прошлой неделе» или «Orderhistory by Date»). Поскольку GUID имеет тенденцию равномерно распределяться по таблице, вы не сможете получить это преимущество здесь. Также у каждой таблицы может быть только один кластеризованный индекс, поэтому тщательно выбирайте.

Если вы запрашиваете таблицу, наиболее полезную для определенного диапазона, тогда рассмотрите ее как кластерный индекс.

Существует также 3-й вид, который называется индексом покрытия. Индекс покрытия состоит из нескольких полей, которые смогут удовлетворить самый общий запрос. Например, у вас есть таблица USER с идентификатором, отображаемым именем, паролем, LogonDate и т. Д., И вам понадобится DisplayName часто, создавая индекс на основе идентификатора, Displayname будет считаться индексом покрытия для запроса, такого как

Select Displayname from USER where ID=XYZ

Edit: Одна вещь, которую я забыл упомянуть. GUID - довольно большой объект, когда дело доходит до SQL (ну ... 16 байт). Наличие в нем кластерного индекса заставляет все остальные индексы в этой таблице включать 16-байтовый указатель на GUID. Это может складываться, если у вас есть куча индексов на этой таблице. Theclustered индекс лучше всего, он маленький и уникальный. Вот почему INTs настолько хороши.