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

Question

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

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

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

Я знаю, что на эту тему опубликовано много других вопросов, но я не нашел конкретного ответа, который я ищу, ни в одном из них:
Должен ли столбец первичного ключа Sequential Guid быть кластеризованным индексом?
Повышение производительности первичного ключа GUID индекса кластера
Кластерный первичный ключ для столбца с уникальным идентификатором в SQL Server
уникальный идентификатор с индексом
Должен ли я избавиться от кластеризованных индексов в столбцах Guid

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

Основным преимуществом кластеризованного индекса является возможность извлекать «диапазоны» данных (например, «последний»).неделя "или" История заказов по дате ").Поскольку GUID имеет тенденцию равномерно распределяться по столу, вы не сможете получить это преимущество здесь.Кроме того, у каждой таблицы может быть только один кластеризованный индекс, поэтому выбирайте осторожно.

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

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

Select Displayname from USER where ID=XYZ

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