为何顺序键非聚集索引未出现PAGELATCH_EX与PAGELATCH_SH？

核心差异：聚集索引与非聚集索引的 latch 竞争逻辑不同 #

你之前遇到的PAGELATCH问题，主要源于聚集索引的叶子节点就是数据页——所有插入操作都要直接修改这些存储整行数据的页，一旦并发量上来，大量线程争抢同一批数据页的 latch，很容易形成阻塞。而基于插入日期的非聚集索引，本质上是单独的索引结构，和聚集索引的竞争场景有本质区别：

• 单页承载量更高，竞争频率更低
  非聚集索引的叶子节点只存储日期键和对应的书签（聚集键或RID），单条记录体积远小于聚集索引的整行数据。这意味着单页能容纳更多索引条目，相同插入量下，页分裂的频率更低，需要争抢的目标页数量更少，自然不容易触发 latch 冲突。

• 写入操作更轻量化，latch 持有时间短
  插入非聚集索引时，仅需在索引页末尾追加一条小条目，操作耗时极短，latch 的持有时间远短于聚集索引的整行写入。线程快速释放 latch，后续等待的线程无需长时间排队，很难形成大规模的竞争阻塞。

额外缓解因素 #

除了结构差异，还有几个实际场景中的因素可能让这个索引避开了 latch 问题：

• 插入时间的微小分散性
  虽然插入日期是顺序值，但实际业务中插入的时间戳大概率不是绝对连续的（比如不同线程的插入请求有毫秒级偏移），这会让插入点分散到2-3个相邻的索引页，而非集中在单一页上，进一步降低了竞争烈度。
• SQL Server 的内部优化
  对于顺序插入的非聚集索引，SQL Server会提前预分配后续的空白页，避免插入时临时申请页的开销；如果是批量插入场景，还会启用批量索引更新优化，减少单条插入的 latch 竞争。

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