高频UPDATE索引列会引发页分裂、逻辑碎片和统计信息滞后，导致SELECT延迟上升、执行计划误判；碎片率超30%建议重建索引，超60%时查询性能或降3–5倍；需单独更新统计信息，REBUILD锁表，REORGANIZE仅整理碎片。
为什么 UPDATE 多会导致查询变慢
高频 UPDATE（尤其是更新索引列）会引发页分裂、逻辑碎片和统计信息滞后。SQL Server 或 PostgreSQL 的 B+ 树索引不是“原地改”，而是标记旧记录 + 插入新版本，碎片积累后，一次范围扫描可能要跳转几十次磁盘页，SELECT 延迟明显上升，执行计划也容易选错。
- 仅更新非索引列（如
status字段）影响小；更新WHERE条件里常出现的列（如created_at、user_id）最危险 - 碎片率 > 30% 时，重建索引收益显著；> 60% 时，部分查询性能可能下降 3–5 倍
- 统计信息过期（比如表增删改超 20% 行数）会让优化器误判数据分布，选错索引或走全表扫描
SQL Server：重建索引 + 更新统计信息的最小安全操作
别在业务高峰跑 ALTER INDEX ... REBUILD，它锁整张表；用 REORGANIZE 可在线，但只整理逻辑碎片，不释放空间。统计信息必须单独更新——重建索引默认不触发统计更新（除非加 WITH (STATISTICS_NORECOMPUTE = OFF)）。
- 碎片 ALTER INDEX ... REORGANIZE
- 碎片 ≥ 30%：用
ALTER INDEX ... REBUILD WITH (ONLINE = ON)（企业版才支持在线） - 统计信息更新必须显式执行：
UPDATE STATISTICS dbo.orders WITH FULLSCAN, COLUMNS（比默认采样更准，尤其对倾斜数据） - 避免用
sp_updatestats：它跳过未改动过的统计对象，且只做默认采样，容易漏掉关键列
PostgreSQL：VACUUM、CLUSTER 和 ANALYZE 怎么配着用
PG 没有传统“索引重建”概念，VACUUM 清理死元组、回收空间，但不重排数据物理顺序；CLUSTER 才真正按索引重写表，但它锁表且不可并发。高频更新场景下，ANALYZE 比索引整理更紧迫——因为 PG 优化器极度依赖统计精度。
-
VACUUM要常驻：设好autovacuum_vacuum_scale_factor（建议调低至 0.02），否则小表更新几百行就卡住 -
CLUSTER很少需要：仅当某索引被重度用于范围查询且表读远大于写时才考虑，且得停写 -
ANALYZE必须定时跑：ANALYZE orders (order_status, created_at)可针对高频查询列定制采样，比全表ANALYZE更快更准 - 不要依赖
default_statistics_target全局值：对高基数列（如uuid），单独用ALTER TABLE ... ALTER COLUMN ... SET STATISTICS 1000
哪些情况重建索引反而让性能更差
重建不是万能解药，盲目操作可能引入新问题。核心矛盾在于：索引维护本身消耗 IO 和 CPU，且会干扰缓存局部性。
- 表太小（
- 使用了包含大量
INCLUDE列的宽索引：重建后内存中缓存页更大，反而挤占其他热数据空间 - 启用了参数化查询（如
sp_executesql）且参数值分布极不均：重建后统计信息若仍不准，执行计划缓存可能固化错误路径 - 在 Always On 可用性组中重建主节点索引：日志暴涨，可能拖慢同步，甚至触发自动故障转移
碎片和统计不准是症状，不是病因。真正要盯的是 UPDATE 语句本身是否必要、是否可以批量合并、有没有用错隔离级别导致长事务堆积死元组——这些比定期重建重要得多。
