非聚集索引单日碎片化升至50%的最优解决方案是什么？

根本原因分析 #

你观察到的碎片化确实是先插后改的操作逻辑导致的：

• 插入日志时ProviderRequestId为NULL，所有新增的非聚集索引行都会集中在索引的NULL值排序区间，初始索引页填充密度很高
• 后续更新将NULL替换为最长350字节的nvarchar类型值，行长度暴增，超出索引页预留空间后会触发大量页拆分，直接导致索引碎片化快速攀升

方案评估 #

方案1：每日执行索引维护

这个方案是当前场景下投入产出比最高的选择：

• 完全不需要修改现有业务逻辑，原有基于RequestId聚集索引的低延迟查询性能不受任何影响
• 仅需对脚本做基础配置即可：设置碎片化≥30%执行索引重建，5%~30%执行索引重组，低于5%不处理；如果使用SQL Server企业版，开启ONLINE=ON参数可以将维护对业务的影响降到极低水平
• 百万级数据量的非聚集索引维护耗时通常在分钟级，仅需安排在业务低峰期执行即可

方案2：调整业务流程先拿服务商ID再插库

这个方案不推荐使用，缺陷远大于收益：

• 核心业务流程需要大幅调整，还要额外维护分布式ID生成逻辑，开发、测试成本很高
• 依赖服务商接口可用性，如果服务商接口超时或故障会直接导致日志写入失败，数据可靠性大幅下降
• 原有基于自增主键的性能优势被削弱，与你低延迟查询的核心需求相悖

更优优化建议 #

你可以先做索引参数调整，大概率可以大幅降低碎片化增长速度，甚至不需要每日执行维护：
将ProviderRequestId上的非聚集索引填充因子调整为70%~80%，预留足够的页空间用于更新时的行长度增长，从根源上减少页拆分的发生。调整后观察单日碎片化涨幅，如果能降到20%以内，仅需每周执行一次索引维护即可。

最终方案优先级 #

1. 优先调整非聚集索引填充因子，零业务改动成本
2. 若碎片化仍高于预期，配合低峰期索引维护即可
3. 不建议调整核心业务流程

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