为什么在SQL中频繁UPDATE大字段会导致严重的表碎片？-SQL-PHP中文网

alter table t rebuild是mysql 8.0.23+中重建主键、清理update大字段引发的页分裂碎片最有效方式，只重排数据页和索引页、不重置统计信息，避免执行计划突变，且支持并发dml。

为什么在sql中频繁update大字段会导致严重的表碎片？

UPDATE大字段会触发页分裂和空洞残留

InnoDB 的页大小固定为 16KB，当 UPDATE 修改一个 TEXT、BLOB 或长 VARCHAR 字段时，若新值比原值大，原页可能放不下整行数据。此时 InnoDB 不会就地扩容，而是执行页分裂：把部分记录挪到新页，原页留下无法被后续小插入复用的零散空隙——这些就是“逻辑碎片”。更糟的是，大字段常被存储在溢出页（off-page），UPDATE 它还会额外更新溢出页指针和管理结构，放大写放大效应。

频繁更新让碎片无法被自然回收

DELETE 和小 UPDATE 留下的空洞，InnoDB 可通过后续 INSERT 尝试复用；但大字段 UPDATE 导致的页分裂残留空间，往往尺寸不匹配、位置不连续，Purge 线程也无法清理——它只负责标记删除的记录，不整理物理页内碎片。结果是：Data_free 持续上涨，而 innodb_buffer_pool_reads 明显增加，缓冲池命中率下滑。

典型表现：SHOW TABLE STATUS 中 Data_free 占 Data_length + Index_length 超过 20%，且 avg_row_length 波动剧烈
监控重点不是 Data_free > 0，而是 innodb_buffer_pool_read_requests / innodb_buffer_pool_reads 周环比是否跌超 15%
别依赖 OPTIMIZE TABLE：刚重建完，下一次大字段 UPDATE 就又开始分裂

复合索引中含大字段列会加剧问题

如果二级索引定义里包含被频繁更新的大字段（比如 CREATE INDEX idx_status_content ON t(status, content)），每次 UPDATE content 都要同步改这个索引页——即使查询从不 WHERE content。这等于把单次更新放大成多次页分裂，碎片生成速度翻倍。