Значение производительности направляющих COMB

Question

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

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

Контрольный пример:

У меня есть таблица с именем temp (не временная таблица, просто таблица с именем temp) с 585 000 строк в ней. У меня есть новая таблица с именем Codes, и я хочу скопировать все 585 000 значений кода из временной таблицы в таблицу кодов. Выполненный мною тест 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: ЦП время = 17250 мс, прошедшее время = 15735 мс.

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

См. Мой вопрос, в котором я подтверждаю это некоторыми реальными данными из SQL Server и Oracle: StackOverFlow Вопрос

С уважением Massimo

Answer 3

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