批量更新是数据库日常操作中常见的场景，当一次性修改大量表数据时，索引结构会被频繁调整，同时数据分布变化会导致原有统计信息无法准确反映当前表的状态，最终引发索引性能下降的问题。合理的SQL优化和统计信息维护能够有效解决这类问题。
批量更新后索引性能下降的原因
批量更新操作对索引的影响主要体现在两个方面，首先是索引碎片问题，大量数据的增删改会导致索引页出现大量空洞，碎片率升高后，查询时需要扫描更多的索引页，IO消耗增加。其次是统计信息过期，统计信息记录了表数据的分布特征，批量更新后数据分布变化，过期的统计信息会让查询优化器选择错误的执行计划，比如本该走索引扫描却选择了全表扫描。
重新生成统计信息的方法
统计信息的更新是恢复索引性能的重要步骤，不同数据库的操作语法略有差异，以下是常见数据库的实现方式。
SQL Server中重新生成统计信息
SQL Server提供了UPDATE STATISTICS命令来更新统计信息，也可以结合索引重建操作一起执行。
-- 更新指定表的所有统计信息 UPDATE STATISTICS 目标表名; -- 更新指定索引的统计信息 UPDATE STATISTICS 目标表名 索引名; -- 重建索引的同时更新统计信息，FULLSCAN表示全表扫描生成统计信息，更准确但消耗更高 ALTER INDEX 索引名 ON 目标表名 REBUILD WITH (STATISTICS_NORECOMPUTE = OFF, FULLSCAN);
MySQL中重新生成统计信息
MySQL的InnoDB引擎会自动维护统计信息，但在批量更新后也可以手动触发更新。
-- 分析表，更新表的统计信息 ANALYZE TABLE 目标表名; -- 如果索引碎片率过高，可以重建索引 ALTER TABLE 目标表名 DROP INDEX 索引名, ADD INDEX 索引名 (索引列名);
PostgreSQL中重新生成统计信息
PostgreSQL使用ANALYZE命令来更新统计信息，也可以结合VACUUM操作处理碎片。
-- 更新指定表的统计信息 ANALYZE 目标表名; -- 更新指定列的统计信息 ANALYZE 目标表名 (列名); -- 清理死元组并重建索引，减少碎片 VACUUM FULL 目标表名;
批量更新相关的SQL优化技巧
除了更新统计信息，在批量更新操作本身做优化也能减少索引性能的损耗。
- 拆分批量更新批次：不要一次性更新几十万甚至上百万条数据，可以拆分成每次更新1万到5万条的小批次，每批次执行后提交事务，减少索引的连续调整压力。
- 暂时禁用非必要索引：如果批量更新涉及的列不是某些索引的覆盖列，可以在更新前禁用这些索引，更新完成后再重新启用，减少索引维护的开销。
- 避免更新索引列：如果非必要，尽量不要更新索引包含的列，更新索引列会直接触发索引的修改，增加碎片产生的速度。
- 选择合适的更新时机：尽量在业务低峰期执行批量更新操作，同时预留足够的维护时间窗口，更新完成后及时执行统计信息更新和必要的索引重建。
维护后的性能验证
完成统计信息更新和索引优化后，可以通过查询执行计划来验证性能是否恢复。以SQL Server为例，可以使用以下语句查看执行计划：
-- 开启执行计划展示 SET STATISTICS PROFILE ON; -- 执行原来的慢查询 SELECT * FROM 目标表名 WHERE 索引列名 = 目标值; -- 关闭执行计划展示 SET STATISTICS PROFILE OFF;
如果执行计划中原本的全表扫描变成了索引查找，或者扫描的行数明显减少，说明索引性能已经得到有效恢复。同时可以定期监控索引的碎片率，当碎片率超过30%时，建议重新生成索引并更新统计信息。