MySQL 8.4 INSTANT 加列到上限怎么办：TOTAL_ROW_VERSIONS 监控与重建窗口

线上给订单表加个可选字段，MySQL 8.4 基本秒级返回，很顺手。但很多人没注意到，这类 ALGORITHM=INSTANT 变更根本不是完全零后续成本。每次用 INSTANT 模式加列、删列，都会生成新的行版本，累计摸到上限之后，下一次同类变更直接抛 ERROR 4092，你要是反复重试，只会把原本可控的发布窗口拖得越来越长。

遇到 INSTANT 加列报错别死重试，先查下系统表里的 TOTAL_ROW_VERSIONS 数值，快到 64 硬上限的时候提前安排低峰期重建表，把版本计数清零就可以继续正常变更了。

先看清：INSTANT 快的是数据文件，不是变更治理

INSTANT 全程只改数据字典，表里已经存在的行不需要逐行重写，符合条件的操作跑的时候基本不阻塞正常 DML。这个特性非常适合给访问量很高的业务核心表加可选字段，但它相当于把一部分成本从「本次 DDL 耗时」，转移成了「表元数据的版本不断累加」。

MySQL 8.4 官方文档把 INNODB_TABLES.TOTAL_ROW_VERSIONS 作为对应的观测入口。每次走即时模式添加或者删除列，都会生成新的 row version；等计数攒到 64 之后，再想用 ALGORITHM=INSTANT 模式加列删列就会直接失败。

用 INFORMATION_SCHEMA 找到真正接近上限的表

查询的时候先主动限定库名和表名范围，聚焦到你要做发布的业务侧表，别把系统表、历史遗留的临时表也混进来一起判断，平白增加排查工作量：

SELECT NAME,
       TOTAL_ROW_VERSIONS,
       INSTANT_COLS
FROM INFORMATION_SCHEMA.INNODB_TABLES
WHERE NAME LIKE 'shop/%'
ORDER BY TOTAL_ROW_VERSIONS DESC;

NAME 一般会以 库名/表名 的形式呈现，INSTANT_COLS 也可以辅助筛选出还残留着即时列元数据的表。生产环境没必要每分钟跑一次校验，把这个查询逻辑接入每日巡检，或者 DDL 发布前的前置检查步骤就足够。

动手做变更前，先完成三项兼容核对

1. 确认操作类型。只有普通可选列的 ADD/DROP 才有可能走 INSTANT 模式；修改字段类型、调整列顺序这类操作，大概率会触发全表重建。
2. 确认表特征。ROW_FORMAT=COMPRESSED、带 FULLTEXT 全文索引、使用独立数据字典表空间的表、临时表都有对应的使用限制。
3. 确认分区交换计划。分区表一旦走即时模式加列，后续就不能再对该表执行 partition exchange；如果你们的数据归档流程依赖交换分区能力，这个点必须先列为发布阻断项，核对完再推进。

ALTER TABLE shop_order
  ADD COLUMN risk_level TINYINT NULL,
  ALGORITHM=INSTANT;

把执行算法明确写到 DDL 语句里的好处，就是不会因为默认算法的版本悄咪咪变动，直接把原本预期秒级完成的发布变成全表重建。对没法接受隐式升级执行算法的线上变更场景，也可以让你的 DDL 发布平台在发现不满足 INSTANT 条件时直接报错终止，由人工评估确认之后再选择合适的发布窗口执行。

碰到 ERROR 4092，怎么把重建放进可控窗口

这个报错根本不是你写的新列定义有问题，只是这张表的即时行版本数已经踩到硬上限了。碰到报错先停手别反复重试，先把当前 DDL 内容、表存量大小、写入峰值、从库复制延迟这几个信息都记录好，再选合适的重建路径。

ERROR 4092 (HY000): Maximum row versions reached for table shop_order.
No more columns can be added or dropped instantly.

重建操作会把全表行重新组织排列，执行完之后 TOTAL_ROW_VERSIONS 就会被直接重置为 0。小表可以直接选业务低峰期走 ALGORITHM=INPLACE, LOCK=NONE 全程在线观测；大表或者没法支持在线 DDL 操作的表，就用提前演练过的 COPY 路径操作，提前评估好剩余磁盘空间、从库延迟波动范围和对应的回滚方案。

重建前后都要留一份验收记录：

SELECT NAME, TOTAL_ROW_VERSIONS
FROM INFORMATION_SCHEMA.INNODB_TABLES
WHERE NAME = 'shop/shop_order';

除了确认行版本计数回到 0 之外，还要核对表行数、主键和所有索引定义、业务侧读写是否正常、从库延迟有没有异常，以及重建之后慢查询指标的变化。只看 DDL 返回执行成功远远不够，表重建带来的 I/O 峰值，很多时候会在命令返回成功之后才慢慢体现到监控指标上。

把行版本检查接入 DDL 发布门禁

可以把每次 schema 变更拆成「预检—执行—复核」三个标准化阶段。预检阶段读取目标表的 TOTAL_ROW_VERSIONS 和所有表特征做校验；执行阶段只允许明确声明了执行算法的语句通过；复核阶段把更新后的行版本数值，和复制延迟、锁等待、业务错误率这些指标一起写入发布记录存档。

常见问题

MySQL 8.4 的 INSTANT 加列一定不会锁表吗？

不一定。符合要求的即时操作通常支持并发 DML，但执行启动阶段还是可能短暂获取元数据锁；如果当前有长事务或者没提交的查询持有相关锁，还是会导致 DDL 等待卡住。

重建表后为什么 TOTAL_ROW_VERSIONS 变成 0？

表重建操作会重新组织全部物理数据和对应的元数据，之前累计下来的所有即时行版本都会被清理掉，计数自然就归零了。

分区表也能放心使用 INSTANT 吗？

操作前先核对后续业务流程。官方明确标注了限制，分区表走 INSTANT 模式加列之后，就没法再对该表执行 partition exchange 分区交换操作。

把上限调大能解决 ERROR 4092 吗？

不要把这个阈值当成可随便改的配置项处理。正确的处理方式是先安排表重建，清理掉之前积累的行版本，之后再把后续所有 DDL 操作纳入阈值监控体系就可以。

发布前的最小检查清单

• 先记录目标表当前的 TOTAL_ROW_VERSIONS、表存量大小和当时的从库复制延迟数值。
• 确认这次的 ADD/DROP 操作只包含支持 INSTANT 的动作，并且语句里明确写好了对应的执行算法。
• 提前确认分区交换、FULLTEXT 全文索引、压缩行格式这些边界条件不会触发限制。
• 把 48、57、64 三个阈值接入 DDL 审批流程和告警规则里。
• 表重建完成之后，复查行版本计数、所有索引定义、业务读写状态和从库运行情况。