多来源并发插入时，如何减少非标识列主键冲突？

嘿，针对你在SQL Server 2012里遇到的多数据源并发插入EmailRequest表时非标识列主键冲突的问题，我结合SQL Server 2012的特性和你的场景，整理了几个实用的解决方案，你可以根据实际情况选择：

1. 用序列（Sequence）生成全局唯一主键值 #

SQL Server 2012开始支持序列对象，这是比标识列更灵活的主键生成方式，非常适合多数据源并发场景。序列是数据库级别的全局对象，所有数据源都从同一个序列获取ID，天然不会重复，还能通过缓存减少锁竞争。

实现步骤： #

首先创建序列：

CREATE SEQUENCE dbo.EmailRequestIDSeq
    AS INT
    START WITH 1 -- 可以根据现有数据的最大ID调整起始值
    INCREMENT BY 1
    MINVALUE 1
    MAXVALUE 2147483647 -- int类型的最大值
    CACHE 100; -- 缓存100个ID，提升高并发下的性能

然后插入数据时，直接调用序列获取主键值：

INSERT INTO dbo.EmailRequest (EmailRequestID, EmailAddress, CCEmailAddress, ...)
VALUES (NEXT VALUE FOR dbo.EmailRequestIDSeq, 'user@example.com', 'cc@example.com', ...);

优势：无需协调多个数据源，数据库自动保证ID唯一性，性能优异，适合绝大多数高并发场景。

2. 给每个数据源分配独立的ID范围 #

如果不想依赖序列，可以预先给每个数据源分配一段不重叠的ID区间。比如：

• 数据源A：使用1~100000的ID
• 数据源B：使用100001~200000的ID
• 以此类推，后续扩容时再分配新的区间

每个数据源只在自己的范围内生成ID，从根源上避免了主键冲突。

优势：完全消除跨数据源的ID竞争，不需要数据库层面的协调；注意点：需要提前规划好ID范围，后续扩容时要调整区间，适合数据源数量固定的场景。

3. 改用GUID作为主键 #

如果可以修改表结构，把EmailRequestID的类型改成UNIQUEIDENTIFIER，每个数据源插入时生成唯一的GUID即可。推荐用NEWSEQUENTIALID()生成有序GUID，减少索引碎片，性能比NEWID()更好。

实现步骤： #

先修改表结构（如果现有数据允许的话）：

-- 先删除原有主键约束
ALTER TABLE dbo.EmailRequest DROP CONSTRAINT PK_EmailRequest;

-- 修改列类型
ALTER TABLE dbo.EmailRequest ALTER COLUMN EmailRequestID UNIQUEIDENTIFIER NOT NULL;

-- 重新添加主键约束
ALTER TABLE dbo.EmailRequest ADD CONSTRAINT PK_EmailRequest PRIMARY KEY (EmailRequestID);

插入数据时生成GUID：

INSERT INTO dbo.EmailRequest (EmailRequestID, EmailAddress, ...)
VALUES (NEWSEQUENTIALID(), 'user@example.com', ...);

优势：每个数据源独立生成ID，无需任何协调，适合数据源动态变化的场景；注意点：GUID占用更多存储空间，索引效率略低于int类型，适合对主键性能要求不是极致的场景。

4. 乐观锁+冲突重试机制 #

如果必须保留当前的int主键且无法使用序列/范围分配，可以在插入时捕获主键冲突错误，然后重试插入（重新生成一个ID再尝试）。

SQL层面示例： #

DECLARE @GeneratedID INT = 123; -- 这里替换成你当前生成ID的逻辑
DECLARE @EmailAddress VARCHAR(1024) = 'user@example.com';

BEGIN TRY
    INSERT INTO dbo.EmailRequest (EmailRequestID, EmailAddress, ...)
    VALUES (@GeneratedID, @EmailAddress, ...);
END TRY
BEGIN CATCH
    -- 捕获主键冲突错误（错误码2627）
    IF ERROR_NUMBER() = 2627
    BEGIN
        -- 重新生成ID（这里可以根据你的逻辑调整，比如加1或用其他算法）
        SET @GeneratedID = @GeneratedID + 1;
        -- 重试插入
        INSERT INTO dbo.EmailRequest (EmailRequestID, EmailAddress, ...)
        VALUES (@GeneratedID, @EmailAddress, ...);
    END
    -- 其他错误可以抛出或处理
    ELSE
    BEGIN
        THROW;
    END
END CATCH

优势：无需修改现有主键生成逻辑；注意点：并发量高时重试次数会增加，影响性能，适合并发量较低的场景。

5. 搭建集中式ID生成服务 #

如果你的系统架构允许，可以搭建一个独立的ID生成服务，所有数据源在插入前先调用这个服务获取唯一的EmailRequestID。服务可以用以下方式实现：

• 基于SQL Server的序列（本质是把序列封装成服务）
• 基于Redis的原子递增命令（比如INCR）
• 自定义雪花算法生成ID

优势：统一管控ID生成，适合复杂的多数据源、多数据库场景；注意点：增加了系统复杂度，需要维护额外的服务组件。

内容的提问来源于stack exchange，提问作者user6150786