Jimmy Nilsson diskutiert sein COMB-Guid-KonzeptHier. Dieses Konzept ist in NHibernate unter anderem wegen seines vermeintlichen Leistungswerts gegenüber Standard-GUIDs, die in der Regel weitaus zufälliger sind, beliebt.

Beim Testen scheint dies jedoch nicht der Fall zu sein. Vermisse ich etwas?

Testfall:

Ich habe eine Tabelle mit dem Namen temp (keine temporäre Tabelle, nur eine Tabelle mit dem Namen "temp") mit 585.000 Zeilen darin. Ich habe eine neue Tabelle mit dem Namen Codes und möchte alle 585.000 Codewerte aus der temporären Tabelle in die Codetabelle kopieren. Das von mir ausgeführte Test-SQL war:

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

Leistung mit Standard-GUID-Werten:

SQL Server-Ausführungszeiten: CPU-Zeit = 17250 ms, verstrichene Zeit = 15735 ms.

(585000 Zeile (n) betroffen)

Leistung mit COMB-GUID-Werten:

SQL Server-Ausführungszeiten: CPU-Zeit = 17500 ms, verstrichene Zeit = 16419 ms.

(585000 Zeile (n) betroffen)

Was vermisse ich? Die COMB-GUID-Werte führten zu etwas längeren Zeiten, vermutlich aufgrund der zusätzlichen Konvertierungen. Ich dachte, der Punkt wäre, die Einfügezeit zu reduzieren, indem die GUIDS nach dem Datum der letzten 6 Bytes sortiert werden, aber der Leistungsgewinn scheint nicht zu existieren.