Неожиданные результаты производительности при сравнении INT с BIGINT для столбцов IDENTITY

Question

Меня попросили выполнить тест производительности с использованием SQL Server 2008. В рамках этого я сравниваю скорость столбцов IDENTITY как PK, используя INT и BIGINT. У меня есть простая процедура для создания 100 000 строк для каждого типа и времени вставки. Сценарий выглядит так:

SET NOCOUNT ON

CREATE TABLE TestData
(
    PK      INT IDENTITY PRIMARY KEY,
    Dummy   INT
)

DECLARE @Rows   INT
DECLARE @Start  DATETIME

SET @Rows = 100000
SET @Start = GETDATE()

WHILE @Rows > 0
BEGIN
    INSERT INTO TestData (Dummy) VALUES (@Rows)
    SET @Rows = @Rows - 1
END

SELECT @Start, GETDATE(), DATEDIFF(MS, @Start, GETDATE())

DROP TABLE TestData

Для тестирования идентичностей BIGINT я использую очень немного измененную версию:

SET NOCOUNT ON

CREATE TABLE TestData
(
    PK      BIGINT IDENTITY PRIMARY KEY,
    Dummy   INT
)

DECLARE @Rows   INT
DECLARE @Start  DATETIME

SET @Rows = 100000
SET @Start = GETDATE()

WHILE @Rows > 0
BEGIN
    INSERT INTO TestData (Dummy) VALUES (@Rows)
    SET @Rows = @Rows - 1
END

SELECT @Start, GETDATE(), DATEDIFF(MS, @Start, GETDATE())

DROP TABLE TestData

К моему удивлению, версия BIGINT работает заметно быстрее, чем версия INT. Версия INT в моем тестовом наборе занимает около 30 секунд, а BIGINT - около 25 секунд. Конечно, тестовый набор имеет 64-битный процессор. Однако он работает под управлением 32-разрядной Windows и 32-разрядной версии SQL Server 2008.

Может ли кто-нибудь еще воссоздать, опровергнуть, подтвердить или оспорить результаты или указать, если я что-то пропустил?

Answer 1

Server1 - На SQL2005 SP3 64-bit ... Я только что попробовал (INT, затем BIGINT) и получил 2,9 и 2,6 с. Затем, подняв строки до 500000, я получил 15,2 и 15,3 с.

• Больше 500K INT / BIGINT работает: 14,0 / 14,6 с; 14.0 / 15.3s; и 14,7 / 15,3 с. Таким образом, INT на 5,8% быстрее, чем BIGINT.
• Изменение порядка на BIGINT / INT: 15,4 / 13,8 с; 15.3 / 15.4s; и 12,9 / 12,7 с. INT здесь на 4% быстрее.

Сервер2 - На SQL2000 SP4 EE ...

• INT / BIGINT: 13,7 / 10,9 с; 10.4 / 13.9s; 9.9 / 10.2s. INT быстрее на 2,9%.
• Затем переключение на BIGINT / INT: 10,2 / 13,3 с; 10.2 / 10.1s; и 11,2 / 10,0 с. BIGINT быстрее на 5,7%.

В основном INT часто, но не всегда быстрее, чем BIGINT, , но не из-за различий, которые я наблюдаю на трассах.

Answer 2

Чтобы сделать шаг вперед, проделайте то же самое с VARCHAR, например:

SET NOCOUNT ON

CREATE TABLE TestData
(
    PK          VARCHAR(8) PRIMARY KEY,
    Dummy       INT
)

DECLARE @Rows   INT
DECLARE @Start  DATETIME

SET @Rows = 100000
SET @Start = GETDATE()

WHILE @Rows > 0
BEGIN
    INSERT INTO TestData (PK, Dummy) VALUES (CONVERT(VARCHAR(8), @Rows), @Rows)
    SET @Rows = @Rows - 1
END

SELECT @Start, GETDATE(), DATEDIFF(MS, @Start, GETDATE())

DROP TABLE TestData

Я ожидал бы, что это будет намного медленнее, поскольку скрипт определяет столбец «identity», и есть преобразования строк. Также я сделал VARCHAR (8), чтобы количество байтов совпадало с bigint. Тем не менее, в моих тестах это работает быстрее, чем тест INT сверху.

Что я понял из этого, так это то, что вставка записей в пустую таблицу будет довольно быстрой, независимо от того, что вы к ней добавите. Последствия производительности в будущем, то есть другие индексы в таблице, вставка строк, когда в таблице уже много данных, и т. Д., Вероятно, гораздо более важный фактор.

Answer 3

Я пробовал это на моем SQL2008. INT занимает 14 сек. BIGINT занимает 18 секунд.

Answer 4

Просто предположение: вы когда-нибудь пытались сначала протестировать BIGINT, а потом INT? Серверы баз данных любят хранить вещи в памяти для оптимизации подобных операций ...