用随机化BigInt ID替代GUID解决PAGELATCH问题的可行性探讨

背景 #

我们有两张每分钟接收100万+插入请求的表，表上建有大量索引且因业务需求无法移除。由于插入量极高，出现了PAGELATCH_EX和PAGELATCH_SH锁，直接导致插入速度大幅下降。

常规方案的痛点 #

行业内普遍认可的解决方案是把标识列改为GUID，让每次插入写入随机页面来避免 latch 竞争。但修改主键类型需要开发迁移脚本适配现有生产数据，涉及完整的开发测试上线周期，时间和人力成本都很高。

我尝试的替代方案 #

我设计了另一种方案，在负载测试中表现良好：不替换成GUID，而是通过以下逻辑生成随机化的BigInt类型ID，既保留了BigInt主键比GUID更高的效率，又彻底消除了PAGELATCH_EX和PAGELATCH_SH锁，插入速度显著提升：

SELECT @ModValue = (DATEPART(NANOSECOND, GETDATE()) % 14);
INSERT xxx(id)
SELECT NEXT VALUE FOR Sequence * (@ModValue + IIF(@ModValue IN (0,1,2,3,4,5,6), 100000000000,-100000000000))

该方案的核心逻辑是利用当前时间的纳秒值取模得到0-13的数值，然后给Sequence生成的ID乘以一个正负超大倍数，让ID分散到正负两个极大的区间，从而避免插入时集中写入同一页面。

团队的疑虑 #

部分团队成员对这个方案存在顾虑：

• 随机生成正负ID的逻辑并非通用方案，可能存在场景局限性
• 运维团队在日常操作中可能会因大数值负ID产生困扰（比如数据排查、导出时的异常感知）
• 需要改变团队里select * from table order by 1这类依赖主键默认排序的常见操作习惯

寻求社区意见 #

想了解社区对该方案的看法，恳请大家指出这个方案的潜在劣势和风险点。

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