Последовательный Гуид и фрагментация
Я пытаюсь понять, как последовательный гуид работает лучше, чем регулярный гуид.
Это потому что с регулярным гуидом, индексное использование последний байт гуида к виду? Так как это случайно, это вызовет большую фрагментацию и расщепления страницы, так как это будет часто перемещать данные в другую страницу для вставки новых данных?
Последовательный синус гуида это последовательно, это вызовет намного меньше расщеплений страницы и фрагментации?
Мое понимание корректно?
Если кто-либо может пролить больше света на предмет, я буду, ценил очень.
Спасибо
Править:
Последовательный гуид = NEWSEQUENTIALID (),
Регулярный гуид = NEWID ()
2 ответа
Вы почти все сказали в своем вопросе.
С последовательным идентификатором GUID / первичным ключом новые строки будут добавляться вместе в конце таблицы, что упрощает работу с SQL-сервером. Для сравнения, случайный первичный ключ означает, что новые записи могут быть вставлены в любом месте таблицы - вероятность того, что последняя страница таблицы окажется в кеше, весьма высока (если это то место, где происходят все чтения), однако вероятность того, что случайная страница в середине таблицы, находящейся в кеше, имеет довольно низкий размер, что означает, что требуется дополнительный ввод-вывод.
Вдобавок ко всему, при вставке строк в середину таблицы существует вероятность того, что недостаточно места для вставки дополнительной строки. Если это так, то SQL-серверу необходимо выполнить дополнительные дорогостоящие операции ввода-вывода, чтобы создать место для записи - единственный способ избежать этого - разбросать пробелы между данными, чтобы можно было вставить дополнительные записи (известные как Фактор заполнения), что само по себе вызывает проблемы с производительностью, поскольку данные распределяются по большему количеству страниц, и поэтому для доступа ко всей таблице требуется больше операций ввода-вывода.
Я полагаюсь на мудрость Кимберли Л. Трипп по этой теме:
Но GUID, который не является последовательным - как тот, у кого есть свои ценности генерируется на клиенте (с использованием .NET) ИЛИ сгенерировано функцией newid () (в SQL Server) может быть ужасно плохим выбор - в первую очередь из-за фрагментация, которую он создает в базовая таблица, но и из-за ее размер. Неоправданно широкая (это 4 раз шире, чем идентичность на основе int - что может дать вам 2 миллиарда (на самом деле, 4 миллиарда) уникальных строк). И, если вам нужно больше 2 миллиардов, вы всегда можно использовать bigint (8-байтовый int) и получаем 263-1 строки.