DELETE导致索引碎片率飙升是B-tree结构必然现象：删除仅标记行、不回收空间，造成页内空洞和逻辑断裂；盲目重建可能锁表、耗资源，需分场景处理。
DELETE 后索引碎片率飙升不是“意外”，而是 B-tree 索引结构在删除大量行时的必然反应：页内留下空洞、逻辑顺序断裂、后续插入触发频繁页分裂。直接重建索引能清掉碎片，但必须分清场景——盲目 REBUILD 可能锁表、耗空间、甚至让问题更糟。
DELETE 为什么会让 avg_fragmentation_in_percent 突然跳到 60%+
根本原因不是删数据本身，而是删法 + 索引结构共同作用的结果：
- DELETE 只标记行“已删除”，不立即回收页内空间 → 页填充率（
avg_page_space_used_in_percent）骤降，内部碎片激增 - 若被删的是聚集索引中间段（比如按时间范围删历史订单），叶级页出现大段空白 → 页链断裂，
avg_fragmentation_in_percent中的“逻辑碎片”部分飙升 - 后续 INSERT/UPDATE 若继续用随机主键（如
NEWID()或 UUID），新数据无法填满旧空洞，反而在别处开新页 → 外部碎片雪上加霜 - MySQL 的
DELETE还会阻塞 Purge 线程及时清理，空洞长期滞留；SQL Server 则依赖自动或手动更新统计信息，否则优化器仍按“满页”估算执行计划
SQL Server：重建前必须确认三件事
在运行 ALTER INDEX ... REBUILD 前，跳过这三步大概率翻车：
- 查清是哪个索引真高碎：
SELECT OBJECT_NAME(object_id), name, avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') i JOIN sys.indexes idx ON i.object_id = idx.object_id AND i.index_id = idx.index_id WHERE avg_fragmentation_in_percent > 30 - 确认当前是否允许锁表：Standard 版
REBUILD默认锁表；如不能停写，改用REORGANIZE（但只对 ≤30% 有效），或 Enterprise 版加WITH (ONLINE = ON) - 主键重建要命：InnoDB 没这问题，但 SQL Server 中重建聚集索引（即主键）会连带重建所有非聚集索引 → 耗时翻倍、日志暴涨；优先考虑
REORGANIZE或只重建问题非聚集索引
MySQL：OPTIMIZE TABLE 不等于安全重建
OPTIMIZE TABLE 在 MySQL 中本质是重建，但行为因引擎而异，踩坑点极多：
Ainee: AI Notetaker
下载
一款AI办公效率工具，主要用于Your ultimate AI-powered notetaking and learning companion.，适合需要提升相关任务效率的用户。
- InnoDB 下等价于
ALTER TABLE ... FORCE，会新建表、拷数据、换名、删旧表 → 需要 **2 倍磁盘空间**，且全程锁表（5.7+ 支持ALGORITHM=INPLACE仅限某些操作，但OPTIMIZE不在此列） - MyISAM 下
OPTIMIZE是先REPAIR再ANALYZE，但会锁整个表，且不适用于大表在线维护 - 从库上禁用：
OPTIMIZE TABLE不写 binlog（statement 格式下），备库可能卡在Waiting for table metadata lock，甚至中断复制 - 替代方案更可控：用
ALTER TABLE t ENGINE=InnoDB（5.6+ 支持 online DDL）、或分批INSERT INTO t_new SELECT * FROM t WHERE id BETWEEN x AND y+ 重命名切换
重建后不更新统计信息 = 白干
碎片清了，但优化器“看不见”——这是最常被忽略的一环：
- SQL Server：重建后默认不更新统计信息（除非显式加
STATISTICS_NORECOMPUTE = OFF），务必补一句UPDATE STATISTICS table_name index_name或确保数据库级AUTO_UPDATE_STATISTICS开启 - MySQL：InnoDB 在
OPTIMIZE TABLE后会自动更新统计信息；但手动ALTER TABLE重建后，建议显式执行ANALYZE TABLE table_name，尤其当rows字段明显不准时 - Oracle：重建索引后必须
ANALYZE INDEX index_name COMPUTE STATISTICS或用DBMS_STATS.GATHER_INDEX_STATS，否则 CBO 仍按旧分布估算，可能继续走全表扫描
重建不是终点，而是观察起点：碎片率回落只是表象，真正要看的是查询执行计划是否改走索引、logical reads 是否下降、慢查是否消失。一次重建解决不了触发器里逐行写日志带来的持续分裂，也掩盖不了 UUID 主键设计的根本缺陷。
