identity列会不会成为高并发插入的瓶颈?

Question

单独执行存储过程,响应时间一般在30ms左右,
在高并发的(100条/秒)情况下,有时会到200-300ms,
存储过程有一个插入语句,目标表现在有1000W数据,同时有一个identity列,
我想在高并发插入的时候,因为要维持一致性,会不会像mysql一样有一个AUTO_INC锁,这个锁导致并发性能下降?
是不是在有高并发插入的表里不用identity列比较好?

Answer 1

identity列不要加索引，表也不要加索引。

Answer 2

高并发插入的情况下，获取数据页/PFS/GAM页锁的时间会占多数时间，优化存储/表结构可能才是关键。

Answer 3

可以去掉IDENTITY列，可以通过异步机制生成递增列。好处可以减少并发锁定的时间，但是生成的序列可能有间断

Answer 4

--内幕如是说
异步生成序列--步骤1：建立一个带有标识列的 AsyncSeqCREATE TABLE AsyncSeq(val INT IDENTITY(1,1))--步骤2：建立SP Usp_AsyncSeq，生成新的序列值并通过输出参数@val返回
CREATE PROC Usp_AsyncSeq
@VAL INT OUTPUT
AS 
BEGIN TRAN
SAVE TRAN S1;
INSERT INTO AsyncSeq DEFAULT VALUES;
SET @VAL=SCOPE_IDENTITY()
ROLLBACK TRAN S1;
COMMIT TRAN
GO/*说明：
该存储过程打开一个事务并创建保存点S1。它在AsyncSeq表中插入一个
新的标识值并保存到@val中。然后回滚INSERT操作。但是回滚不会撤销变量
赋值，也不会撤销递增标识值的操作。而且，标识资源不会在外部事务期间
被锁定，只是在递增时锁定一小下。identity属性的这个行为时异步序列机
制的关键所在。
回滚到保存点可以保证操作不会影响外部事物。回滚可以防止AsyncSeq
表增长。这样AsyncSeq就不存在任何行。

*/
--示例
--如果你想得到下一个序列号，运行Usp_AsyncSeq，就和同步机制时一样
--好处是在外部事务中递增序列不会阻塞序列。不足是一次只生成一个序列。
declare @val int
exec Usp_AsyncSeq @val output
select @val
(1 行受影响)
           
-----------
          1(1 行受影响)--如果需要重置序列的时候执行TRUNCATE TABLE AsyncSeqORDBCC CHECKIDENT('DBO.AsyncSeq',RESEED,0)

Answer 5

要维持identity列不重复,不跳跃,高并发下有这个列和没有这个列,性能应该有差异吧?

Answer 6

其实有没有identity影响不是太大,只是想知道这个有没有可能成为瓶颈