Производительность команд COMB

Джимми Нильссон обсуждает концепцию концепции COMB здесь. Эта концепция популярна в NHibernate, среди других кругов, для предполагаемого значения производительности по сравнению с стандартными идентификаторами GUID, которые обычно намного более случайны.

Однако при тестировании это, похоже, не так. Я что-то пропустил?

Тестовый пример:

У меня есть таблица под названием temp (не временная таблица, а только таблица с именем temp) с 585 000 строк в ней. У меня есть новая таблица под названием "Коды" и вы хотите скопировать все 585 000 значений кода из таблицы temp в таблицу кодов. Выполненный мной SQL-тест:

set statistics time on;

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select newid(), codevalue from temp

truncate table codes;
DBCC DBREINDEX ('codes', '', 90);

insert into codes (codeid, codevalue)
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp

Производительность со стандартными значениями GUID:

Время выполнения SQL Server: CPU время = 17250 мс, прошедшее время = 15735 мс.

(затронуто 585000 строк)

Производительность с значениями GUID COMB:

Время выполнения SQL Server: CPU время = 17500 мс, прошедшее время = 16419 мс.

(затронуто 585000 строк)

Что мне не хватает? Значения COMB GUID привели к чуть более продолжительным временам, по-видимому, из-за дополнительных преобразований. Я думал, что дело в том, чтобы уменьшить время вставки путем полуупорядочения GUIDS с использованием даты для последних 6 байтов, но прирост производительности не существует.

Ответ 1

Во-вторых, вы увидите различия только в том случае, если у вас есть индексы (PK, FK или другие типы индексов, сгруппированные или не сгруппированные) в столбце Guid, поскольку стоимость стандартного guid или newguid или comb guid обусловлена высокая стоимость переупорядочивания данных индекса каждый раз, когда выполняется вставка.

См. мой вопрос, в котором я подтверждаю это с некоторыми реальными данными из SQL Server и Oracle: fooobar.com/questions/94938/...

Отношения Massimo

Ответ 2

Я бы предположил, что вы не видите выигрыш в заказе, потому что в целевой таблице нет ПК. Итак, это накладные расходы на конвертацию, которые вы видите. Если он имеет PK, строки 585k все равно должны быть отсортированы на вставке. Как SQL знает, что он полусортирован?

Теперь, если это было 5 850 x 100 строк вставки, вы можете увидеть некоторую выгоду, потому что новые строки будут идти "в конце", а не "посередине", что уменьшит разбиение страниц и накладные расходы.

Я пошел дальше и скажу, что статья датирована 2002 годом и предназначена для SQL 2000, и ее охватила реальная жизнь.

В SQL Server 2005 у нас есть ПОСЛЕДОВАТЕЛЬНЫЕ GUID, позволяющие строго монотонным GUID решать некоторые проблемы. Здесь также был указан GUID как ПК: недавний пример: INT vs Unique-Identifier для поля ID в базе данных с сторонними ссылками.

Если ORM определяет GUID как ПК, а не естественный ключ или стандартный суррогатный ключ на основе int, это серьезное ограничение ORM. И случай хвоста клиента виляет собакой базы данных.

Ответ 3

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