В SQL Server 2008 я пытался воспроизвести результаты экспериментов с кластеризованным индексом для последовательных и непоследовательных ключей GUID, которые можно увидеть здесь http://sqlblog.com/blogs/denis_gobo/archive/2009/02/05/11743.aspx, но я не испытываю значительного ускорения вставок, которое я бы сделаложидаем (и автор переживает).Использование страницы явно улучшено благодаря последовательному идентификатору GUID, но по некоторым причинам вставка 10000 строк происходит всего на 100 мс быстрее (из 10 300 мс).
Я использую следующий код:
CREATE TABLE TestGuid1 (Id UNIQUEIDENTIFIER not null DEFAULT newid(),
SomeDate DATETIME, batchNumber BIGINT)
CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER not null DEFAULT newsequentialid(),
SomeDate DATETIME, batchNumber BIGINT)
CREATE CLUSTERED INDEX ix_id1 ON TestGuid1(id)
CREATE CLUSTERED INDEX ix_id2 ON TestGuid2(id)
go
SET NOCOUNT ON
INSERT TestGuid1 (SomeDate,batchNumber) VALUES (GETDATE(),3)
go 10000
SET NOCOUNT ON
INSERT TestGuid2 (SomeDate,batchNumber) VALUES (GETDATE(),3)
go 10000
DBCC showcontig ('TestGuid1') WITH tableresults
DBCC showcontig ('TestGuid2') WITH tableresults
SELECT batchNumber,DATEDIFF(ms,MIN(SomeDate),MAX(SomeDate))
FROM TestGuid1
GROUP BY batchNumber
SELECT batchNumber,DATEDIFF(ms,MIN(SomeDate),MAX(SomeDate))
FROM TestGuid2
GROUP BY batchNumber
Может кто-нибудь объяснить, почему я не испытываю более значительного ускорения для вставок в TestGuid2?
Последующие действия : Как было предложено в теме ниже, я расширил тест:результаты тестов имеют тенденцию к значительным изменениям во времени, поэтому теперь эксперименты повторяются N раз, и сообщается общее и среднее использование времени.Я также добавил третий тест, а именно для первичных ключей в последовательных целочисленных столбцах.Это должен быть самый быстрый и самый компактный из всех трех методов, поскольку целочисленный тип меньше, а IDENTITY (1,1) является (или, по крайней мере, должен) быть быстрым.По крайней мере, по моей интуиции.Среднее время выполнения теперь выгодно для последовательного GUID, но неожиданно вставки в третьем эксперименте (с последовательными целочисленными ключами) на медленнее , чем последовательные GUID.У меня нет объяснения этому.Вот код для новых экспериментов:
SET NOCOUNT ON
CREATE TABLE TestGuid1 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID() PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))
CREATE TABLE TestGuid2 (Id UNIQUEIDENTIFIER NOT NULL DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))
CREATE TABLE TestInt (Id Int NOT NULL identity(1,1) PRIMARY KEY,
SomeDate DATETIME, batchNumber BIGINT, FILLER CHAR(100))
DECLARE @BatchCounter INT = 1
DECLARE @Numrows INT = 100000
WHILE (@BatchCounter <= 20)
BEGIN
BEGIN TRAN
DECLARE @LocalCounter INT = 0
WHILE (@LocalCounter <= @NumRows)
BEGIN
INSERT TestGuid1 (SomeDate,batchNumber) VALUES (GETDATE(),@BatchCounter)
SET @LocalCounter +=1
END
SET @LocalCounter = 0
WHILE (@LocalCounter <= @NumRows)
BEGIN
INSERT TestGuid2 (SomeDate,batchNumber) VALUES (GETDATE(),@BatchCounter)
SET @LocalCounter +=1
END
SET @LocalCounter = 0
WHILE (@LocalCounter <= @NumRows)
BEGIN
INSERT TestInt (SomeDate,batchNumber) VALUES (GETDATE(),@BatchCounter)
SET @LocalCounter +=1
END
SET @BatchCounter +=1
COMMIT
END
DBCC showcontig ('TestGuid1') WITH tableresults
DBCC showcontig ('TestGuid2') WITH tableresults
DBCC showcontig ('TestInt') WITH tableresults
SELECT batchNumber,DATEDIFF(ms,MIN(SomeDate),MAX(SomeDate)) AS [NEWID()]
FROM TestGuid1
GROUP BY batchNumber
SELECT batchNumber,DATEDIFF(ms,MIN(SomeDate),MAX(SomeDate)) AS [NEWSEQUENTIALID()]
FROM TestGuid2
GROUP BY batchNumber
SELECT batchNumber,DATEDIFF(ms,MIN(SomeDate),MAX(SomeDate)) AS [IDENTITY()]
FROM TestInt
GROUP BY batchNumber
DROP TABLE TestGuid1
DROP TABLE TestGuid2
DROP TABLE TestInt
И среднее время выполнения:
NEWID() 3064
NEWSEQUENTIALID() 1977
IDENTITY() 2223
Использование страницы выглядит следующим образом:
Table Pages AveragePageDensity
----------------------------------------
TestGuid1 50871 68,4
TestGuid2 35089 99,2
TestInt 32259 98,7
Я не понимаю, почему эта статистика страниц (которые лучше всего подходят для TestInt) не означает, что эксперимент третий является самым быстрым.