非连续唯一标识符场景下主键创建的最佳实践

核心结论 #

优先给表添加一个自增的Identity列作为聚集主键，同时为供应商提供的Call ID创建非聚集唯一索引——这是5000万+行级大表场景下的最优实践。

为什么不直接用供应商Call ID当主键？ #

• 页分裂问题严重：聚集索引的叶子节点就是实际的数据存储页，若主键值不连续（如你的Call ID出现跳段），插入新数据时数据库频繁需要拆分现有满页来腾空间，也就是「页分裂」。大表反复经历这个过程会导致磁盘IO飙升、数据碎片增多，不管是写入还是后续查询，性能都会大幅下降。而Identity列严格自增，新数据直接追加到数据页末尾，完全避免该问题。
• 业务与存储耦合风险：主键的核心作用是唯一标识行、支撑表关联，无需承载业务含义。供应商的Call ID是业务标识，但生成规则不受你控制（负载均衡导致跳段），将其作为主键会让数据库物理存储依赖外部不可控规则，后续若供应商修改Call ID生成逻辑，你需同步调整，风险极高。

为什么不只用非聚集唯一索引替代主键？ #

若将Call ID设为非聚集主键（需显式指定，多数数据库默认主键为聚集），虽能避免聚集索引的页分裂，但会带来新问题：

• 无聚集索引的表是「堆表」，堆表插入为随机写入，查询依赖行标识符（RID）定位，数据量增大后，查询和表关联效率远低于有序聚集索引的表。
• 非聚集主键本身需维护索引结构，额外占用空间并不比「Identity主键+Call ID非聚集索引」少，还失去了聚集索引的有序性优势。

具体实现建议 #

1. 创建表时添加自增主键：

CREATE TABLE CallRecords (
    CallRecordID INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    SupplierCallID BIGINT NOT NULL,
    -- 其他通话业务字段示例
    CallStartTime DATETIME NOT NULL,
    AgentID INT NOT NULL,
    Duration INT NOT NULL,
    ...
)

2. 为供应商Call ID创建唯一非聚集索引，保障业务唯一性：

CREATE UNIQUE NONCLUSTERED INDEX IX_CallRecords_SupplierCallID 
ON CallRecords(SupplierCallID)

3. 若日常频繁通过Call ID查询通话详情，可将常用查询字段加入索引（覆盖索引），进一步提升查询速度：

CREATE UNIQUE NONCLUSTERED INDEX IX_CallRecords_SupplierCallID 
ON CallRecords(SupplierCallID)
INCLUDE (CallStartTime, AgentID, Duration)

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