Внутреннее соединение PK с Vs Внутреннее соединение PK на SQL Server.План выполнения

Question

Я только что провёл некоторое тестирование соединения Int PK с Guid PK.

Структура таблиц и количество записей выглядят так:

Производительность CRUDоперации с использованием EF4 в обоих случаях довольно похожи.

Хорошо известно утверждение, что Int PK имеет лучшую производительность, чем строки при использовании в соединениях.Таким образом, план выполнения SQL-сервера с ВНУТРЕННИМИ СОЕДИНЕНИЯМИ совершенно отличается

Вот план выполнения:

Как я понимаю в соответствии с планом выполнения сверху, Int joinлучшая производительность, потому что она требует меньше ресурсов для сканирования кластерного индекса, и это происходит двумя способами, я прав?

Может быть, кто-то может объяснить этот план выполнения более подробно?

Достаточно ли этого примера, чтобы показать, что Int PK имеет лучшую производительность в соединениях?

Answer 1

Кимберли Трипп ( Королева индексирования ) имеет отличный пост в блоге на эту тему:

Дисковое пространство дешево ... это не точка!

Она прекрасно показывает, как аргумент "дисковое пространство дешево - использование GUID вместо INT не повредит" во многих отношениях является полностью поддельным.

Answer 2

Если вы подумаете о том, как внутренне компьютер сравнивает значения, это становится очевидным.

• Сравнение двух целых чисел - это быстрая одиночная операция.
• Сравнение 2 16-Для байтовых идентификаторов GUID потребуется несколько инструкций (или одна длинная).

Кроме того, идентификаторы GUID используют в 4 раза больше места, что приведет к увеличению объема подкачки, меньшему использованию кэша и т. д.

Сообщение Кимберли Триппа, упомянутое Марком, доказывает это.

Answer 3

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

1) В реальном случае использования вы, вероятно, не собираетесь объединять две целые таблицы вместе, но будут фильтры для других столбцов и т. Д., Уменьшающие записи, которые будут объединены в одинили обе таблицы.Это будет влиять на то, какой тип алгоритма соединения является наиболее подходящим / наиболее эффективным.

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

2) Какой тип объединения лучше всего подходит при объединении столбцов GUID, во многом зависит от того, как генерируются направляющие.Если вы присоединяетесь ко многим руководствам, которые являются совершенно случайными (например, сгенерированы с помощью SQLID NewID () или CLR Guid.NewGuid ()), то, вероятно, лучшим выбором будет хеш-соединение.Однако если вы присоединяетесь к меньшему набору последовательных (newsequentialid () / UuidCreateSequential ()) или даже к идентичным направляющим, то объединение цикла часто может быть наиболее эффективным выбором.

Оптимизатор использует индексную статистику дляопределить, какой тип объединения использовать, но иногда для сложных запросов со многими объединениями guid может потребоваться принудительное использование типа объединения с помощью подсказок оптимизатора.

---

Короче говоря, если вы пытаетесь это сделатьрешите, следует ли вам использовать GUID или INT PK, тогда более реальный тест - лучший выбор.Создайте таблицы, соответствующие вашему сценарию использования, заполните их достаточным количеством несколько реалистичных образцов данных и выполните некоторые типы запросов, которые, по вашему мнению, вы будете выполнять в дальнейшем.Объединение всего содержимого двух фиктивных таблиц на самом деле ничего не говорит о влиянии ввода-вывода, которое вы можете увидеть при использовании ключей Guid, или о том, как будет выглядеть план выполнения для других запросов, включающих ключи int и guid.

При использовании ключей Guid рассмотрите различные варианты их генерации и имейте в виду, что использование последовательных направляющих часто является хорошим способом избежать чрезмерного чтения страниц, если вы объединяете много записей ...