В базе данных, где все ваши первичные ключи являются идентификаторами GUID, каковы различия/последствия и/или плюсы и минусы с использованием метода newid() или newsequentialid() как "значение по умолчанию или привязка".
Единственное отличие, о котором я знаю, это то, что newid() создает новый случайный GUID, а не newsequentialid() создает новый GUID на основе последнего, который находится в таблице поэтапно.
Как я понимаю, когда вы выполняете вставку в строке DB, она будет вставлена в порядке относительно другой PK в таблице. С помощью обычного guid это может быть где угодно в таблице. Newsequentialid() всегда будет добавлен в конец таблицы.
Таким образом улучшается производительность вставок.
Этот сайт объясняет различия и тесты двух разных методов.
Обновление - ссылка на сообщение в блоге перенесена. Ссылка теперь ссылается на ссылку web.archive.org. Вот ключевой вынос:
Наиболее ярким является количество записей, требуемых системной функцией NEWID. Это, в сочетании со средней плотностью страниц 69%, свидетельствует о расщеплении страницы, вызванном случайным распределением вставок на уровне листа. Как только страница заполнится, ее нужно разделить на 2 страницы по 50% для каждой вставки. Мало того, что разбиение страницы приводило к плохой плотности страницы, она довольно сильно фрагментировала страницы данных (вероятность того, что следующая страница данных не находится рядом с текущей), составляет 99%. В наших тестах наиболее вероятное место для бесплатной страницы, требуемой для разметки страницы, находится в конце таблицы, независимо от того, где находится строка. Поэтому для чтения строк, чтобы сканирование продолжало прыгать назад и вперед между широко распределенными разделенными страницами, отсюда и ужасающая фрагментация.
- Стефан Делмарко
Относительно использования последовательных ключей (как с идентификатором, последовательностью и NEWSEQUENTIALID), так и с несущественными (как с NEWID, так и с помощью специального рандомизированного генератора ключей), необходимо рассмотреть несколько аспектов.
Начиная с последовательных клавиш, все строки идут в правый конец индекса. Когда страница заполнена, SQL Server выделяет новую страницу и заполняет ее. Это приводит к меньшей фрагментации индекса, что выгодно для производительности чтения. Кроме того, вставки могут быть более быстрыми, когда один сеанс загружает данные, а данные хранятся на одном диске или на небольшом количестве дисков.
Однако при использовании подсистем высокого уровня хранения, которые имеют много шпинделей, ситуация может быть разной. При загрузке данных из нескольких сеансов в итоге вы столкнетесь с конфликтом закладок страницы (защелки - это объекты, используемые для синхронизации доступа к страницам базы данных), с самыми правыми страницами связанного списка уровней листа индекса. Это узкое место препятствует использованию полной пропускной способности подсистемы хранения. Обратите внимание: если вы решите использовать последовательные ключи, а youre с помощью числовых, вы всегда можете начинать с самого низкого значения в типе, чтобы использовать весь диапазон. Например, вместо того, чтобы начинать с 1 в типе INT, вы можете начать с -2,147,483,648.
Рассмотрим несекретные ключи, такие как случайные, сгенерированные с помощью NEWID или с помощью специального решения. При попытке заставить строку на уже заполненную страницу SQL Server выполняет классическую разбивку страницы, он выделяет новую страницу и перемещает половину строк с исходной страницы на новую. Разделение страницы имеет стоимость, плюс это приводит к фрагментации индекса. Фрагментация индекса может негативно повлиять на производительность чтения. Однако с точки зрения производительности вставки, если подсистема хранения содержит много шпинделей и вы загружаете данные из нескольких сеансов, случайный порядок может быть лучше, чем последовательный, несмотря на разделение.
Это потому, что в правом конце индекса нет горячей точки, и вы используете подсистемы хранения доступная пропускная способность лучше. Хороший пример для эталона, демонстрирующего эту стратегию, можно найти в блоге Томаса Кейзера в http://blog.kejser.org/2011/10/05/boosting-insert-speed-by-generating-scalable-keys/.
Источник: Запрос Microsoft® SQL Server® 2012 Экзамен 70-461 Учебный комплект
С моей точки зрения, когда экземпляр SQL запускается, идентификатор NEWSEQUENTIALID инициализируется случайным значением. Затем в течение срока действия его GUID увеличиваются на центральном GUID, НЕ просматривая последний GUID, сгенерированный для таблицы.
Как я знаю, NEWID() генерирует GUID в случайном порядке, а NEWSEQUENTIALID() генерирует GUID в последовательном порядке. NEWSEQUENTIALID() может использоваться ТОЛЬКО в стандартном предложении таблицы.