使用身份列或本地序列表的性能影響

我有一個遺留系統正在使用表進行數字排序。該表具有以下定義：使用身份列或本地序列表的性能影響

dbo.id_table 
(
    table_name char(64) NOT NULL, 
    id_type char(5) NOT NULL, 
    data_type char(5) NOT NULL, 
    next_id_number int NOT NULL, 
    next_id_max char(15) NOT NULL 
) 
PRIMARY KEY CLUSTERED 
(
    table_name ASC 
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY]

此表在功能上等同於標識列。

下面是如何使用該表的方法： - 存儲過程運行以獲取表中下一個id值。例如，

exec id_proc 'bryans_table', @some_int_value output

我找專家來回答以下問題：

哪些性能問題（越具體越好）使用一個設計這樣與SQL Server 2008 R2（當前運行在兼容模式下，但計劃在未來的某個時間使用完整的2008 R2）與使用常規標識列？這是否可以擴展？

我們看到很多爭議是這張表，我想知道表是否切換到標識列什麼類型的性能增益可能會（或丟失）？此時爭論的來源不明。

（我不知道爲什麼沒有包括在原設計的標識列 - 這是一箇舊的數據庫）

來源

2013-09-16 Bryan Crosby

您也可以考慮序列，儘管他們具有相同的行爲，性能。 – usr

@usr序列是SQL Server 2012中的新增功能，所以不幸的是它們在這種情況下不起作用 – alroc

此外，您應該詳細說明爲什麼您需要序列表。利用當前信息，他們唯一的優勢是保證連續的ID。 – usr

通過定義這樣的設計意味着最多隻有一個事務可以產生一個新的序列表（因爲記錄上的X鎖正在遞增）。換句話說，所有的INSERT都被序列化（沒有新的INSERT可以繼續，直到第一個INSERT被提交）。性能坦克。

另一方面，IDENTITY能夠同時生成序列。

如果你堅持使用順序表，你可以在一個單獨的事務上生成新的ID，需要單獨連接到服務器，並立即提交增量。或者批量生成（增加+1000）並處理應用代碼中分配的批次。後面的解決方案在緩解爭用方面很有效。但是您鬆散的事務一致性，增量發生在與INSERT分開的事務中，因此您將看到空白，缺少序列等。雖然廣告真相：IDENTITY具有相同的問題（出於同樣的原因......）

來源

2013-09-16 17:37:01

我使用一個使用表來存儲/增加序列號的系統。這張桌子是整個系統的最大瓶頸，並說使用它時的「表演坦克」是一個很大的輕描淡寫。 – alroc

一個考慮因素：數量與業務需求。如果您每秒添加數百行，請使用標識;如果您每分鐘添加的時間不超過幾分鐘，並且您的替代鍵的生成過程中存在古怪的業務規則/要求，則可能需要使用過程。當然，聽起來像音量和爭用是這裏的問題，但是。 –

@Remus Rusanu：非常感謝你的回答。你（或其他人）可能會詳細闡述「性能坦克」的具體細節（可能參考了SQL Server如何在內部處理這個問題）？ –

可以使用生成器表以獲得序列號的，而不必鎖爭用問題

- 影子表

create table dummy_id (
    id int identity not null, 
    dummy int not null 
)

- PROC顯示使用

create proc dummy_id_gen(@newid int output) as 
begin 

begin tran 
insert dbo.dummy_id (dummy) values (0) 
select @newid = scope_identity() 
rollback tran 

end

- 調用PROC來測試它

declare @newid int 
exec dummy_id_gen @newid = @newid output 
select @newid as newid

這仍然只有1行的問題在時間生成的ID

來源

2013-09-16 19:32:30

使用身份列或本地序列表的性能影響

回答

相關問題