B-деревья, базы данных, последовательные и случайные вставки и скорость. Рандом побеждает

переверните операцию, и int будет быстрее ... учли ли вы рост журнала и файла данных? Запускать каждый отдельно

declare @i int, @t1 datetime, @t2 datetime

set @t1 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T2 values (NEWID())
    set @i = @i + 1
END


set @t2 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T1 values (@i)
    set @i = @i + 1
end



select DATEDIFF(ms, @t1, @t2) AS [UID], DATEDIFF(ms, @t2, getdate()) AS [Int]

проблема с UUID заключается в том, что при кластеризации по ним и без использования NEWSEQUENTIALID() они вызывают разрывы страниц и фрагментацию таблицы.

теперь попробуй вот так и увидишь, что это почти то же самое

declare @i int, @t1 datetime, @t2 datetime

set @t1 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T2 values (NEWID())
    set @i = @i + 1
END
select DATEDIFF(ms, @t1, getdate()) 

set @t1 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T1 values (@i)
    set @i = @i + 1
end



select DATEDIFF(ms, @t1, getdate())

И наоборот

declare @i int, @t1 datetime, @t2 datetime



set @t1 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T1 values (@i)
    set @i = @i + 1
end

set @t1 = GETDATE()
set @i = 1

while @i < 10000 begin
    insert into T2 values (NEWID())
    set @i = @i + 1
END
select DATEDIFF(ms, @t1, getdate())

Вы не измеряете скорость INSERT. Вы измеряете производительность сброса журнала. Поскольку вы совершаете коммит после каждого INSERT, все эти тесты сидят без дела в ожидании коммита, чтобы закрепить журнал. Это вряд ли имеет отношение к производительности INSERT. И, пожалуйста, не публикуйте измерения «производительности», когда SET NOCOUNT равен OFF...

Итак, давайте попробуем это без ненужной болтовни между сервером и клиентом, с данными правильного размера, пакетными фиксациями и предварительно выращенными базами данных:

:setvar dbname testdb
:setvar testsize 1000000
:setvar batchsize 1000

use master;
go

if db_id('$(dbname)') is not null
begin
    drop database [$(dbname)];
end
go

create database [$(dbname)] 
    on (name='test_data', filename='c:\temp\test_data.mdf', size=10gb)
    log on (name='test_log', filename='c:\temp\test_log.ldf', size=100mb);
go

use [$(dbname)];
go  

CREATE TABLE [dbo].[T1](
    [ID] [int] NOT NULL
 CONSTRAINT [T1_1] PRIMARY KEY CLUSTERED ([ID] ASC) 
)
GO

CREATE TABLE [dbo].[T2](
    [ID] [uniqueidentifier] NOT NULL
 CONSTRAINT [T2_1] PRIMARY KEY CLUSTERED ([ID] ASC)
)
GO

set nocount on;
go

declare @i int, @t1 datetime, @t2 datetime

set @t1 = GETDATE()
set @i = 1

begin transaction;
while @i < $(testsize) begin
    insert into T1 values (@i)
    set @i = @i + 1
    if @i % $(batchsize) = 0
    begin
        commit;
        begin transaction;
    end
end
commit

set @t2 = GETDATE()
set @i = 1
begin transaction
while @i < $(testsize) begin
    insert into T2 values (NEWID())
    set @i = @i + 1
    if @i % $(batchsize) = 0
    begin
        commit;
        begin transaction;
    end
end
commit

select DATEDIFF(ms, @t1, @t2) AS [Int], DATEDIFF(ms, @t2, getdate()) AS [UID]

drop table T1
drop table T2

INTS: 18 с
GUID: 23 с

КЭД

Я ожидаю, что в реальной базе данных ребалансировка индекса будет незначительной проблемой, потому что многие записи индекса будут помещаться в один блок и иметь такую ​​​​длину.

Что может стать более серьезной проблемой, так это конкуренция за этот единственный блок, содержащий все новые записи. В Oracle есть функция хранения байтов ключа в обратном порядке для распространения новых записей по всем блокам: http://oracletoday.blogspot.com/2006/09/there-is-option-to-create-index.html Не знаю о других базах данных .