MySQL中ON DUPLICATE KEY UPDATE是否会导致额外磁盘空间占用？

问题根因分析 #

该现象确实和INSERT ... ON DUPLICATE KEY UPDATE（简称IODKU）的使用有直接关联，但属于IODKU逻辑与InnoDB存储引擎的底层机制共同作用的结果，具体原因如下：

• InnoDB更新产生的页分裂与碎片：当IODKU触发更新逻辑时，如果被更新的行包含变长字段（如VARCHAR、TEXT、JSON等），更新后行长度变长，超出原有数据页的剩余存储空间时，InnoDB会触发页分裂操作，将原有页拆分为两个新页，拆分后原页会留下大量无法被直接复用的空闲空间。此类高频更新场景下，长期积累的碎片量会非常可观，10倍的空间膨胀基本都是大量碎片导致的，将数据导出后重新导入相当于将所有数据重新排序紧凑存储，空间占用自然会回落至实际数据量对应的大小。
• IODKU的隐式操作加剧空间浪费：IODKU执行时无论最终触发插入还是更新逻辑，都会先尝试分配插入所需的存储空间，即便最终插入失败转更新，该过程预分配的空间也会产生浪费，高并发高频调用场景下的累积效应会非常明显。如果表中存在多个唯一索引，IODKU在做唯一键冲突校验时会产生额外的页写入开销，进一步加剧空间碎片的产生。
• InnoDB表空间回收机制限制：默认配置下InnoDB的共享表空间ibdata文件不会自动收缩，即便是数据删除或碎片整理产生的空闲空间，也只会被标记为可复用，不会释放给操作系统。如果未开启innodb_file_per_table独立表空间配置，undo日志、临时表数据等额外内容也会存储在ibdata文件中，进一步放大空间占用。

同类问题反馈 #

这类问题在高频率更新+IODKU的业务场景（如实时状态同步、设备数据上报、计数统计等）下非常普遍，大量相同技术栈的业务团队都遇到过同类现象，尤其是在表结构中变长字段占比较高的场景下，空间膨胀的速度会更快。 #

缓解方案 #

可以通过以下手段降低空间膨胀的速度，回收空闲空间：

• 开启独立表空间：确认配置项innodb_file_per_table = 1，每张表使用独立的.ibd文件存储数据，后续做碎片整理时不会影响其他业务表，也可以将单表回收的空闲空间释放给操作系统。
• 定期整理碎片：在业务低峰期执行ALTER TABLE 表名 FORCE;，该操作会重建整表数据，将碎片化的存储重新整理为紧凑结构，回收空闲空间，1亿行规模的表需要提前评估执行耗时，避开业务高峰。
• 优化IODKU使用逻辑：如果业务中更新请求占比远高于插入请求，可以调整逻辑为先执行UPDATE，当UPDATE的影响行数为0时再执行INSERT，避免IODKU每次预分配插入空间带来的额外浪费。
• 调整页填充因子：针对该高频更新表，可以将innodb_fill_factor配置调整为80左右，给数据页预留20%的空闲空间用于存储更新后变长的行数据，降低页分裂的触发概率。

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