Azure SQL采用Fill Factor 80重建索引后查询变慢、网络I/O耗时增加问题咨询

• 索引页数量暴增，触发更多I/O传输
  填充因子设为80时，每个索引页只占用80%的空间，剩下20%预留给后续数据更新。但如果你的表以查询为主、几乎没有数据写入操作，重建后索引页数量会比填充因子100%时多约25%。查询需要扫描更多索引页，磁盘读取的数据量变大，这些数据要通过网络传到应用端，直接导致Network I/O耗时飙升，查询自然变慢。

• 部分索引的覆盖能力失效
  如果重建的是部分索引，原本它可能刚好能覆盖常用查询的所有字段需求（也就是覆盖索引）。但重建时要是没严格对齐原索引的键列、包含列，或者填充因子改变让查询优化器换了执行计划——比如原本靠覆盖索引就能完成查询，现在优化器因为索引页变多，选了需要回表的方案，回表会读取更多数据页，进而推高Network I/O。

• 统计信息未及时同步
  重建索引后，SQL Server虽会自动更新统计信息，但针对带过滤条件的部分索引，统计信息可能没准确反映新的索引数据分布。查询优化器拿着过时的统计信息生成低效计划，比如选错了扫描方式，导致读取大量不必要的数据，最终让Network I/O和查询时间都上去了。

• Azure SQL云存储的特性放大了开销
  Azure SQL用的是云存储，索引页变多后，存储层的I/O操作次数会增加，而云存储的I/O延迟对数据量变化更敏感。同时，更多数据页要从Azure存储节点传到计算节点，再传到应用端，整个链路的数据传输量增大，直接体现为Network I/O耗时增加。

• 填充因子不符合业务场景
  80的填充因子一般是给频繁插入、更新的表用的，用来减少页分裂。但如果你的表是只读或极少更新的查询/报表类表，高填充因子（比如100%）才是最优选择。硬套80的填充因子只会浪费存储空间，凭空增加I/O开销，完全不匹配你的业务需求。

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