MySQL 9.7.4 回退了 9.7.3 的 InnoDB 行大小严格校验，INSTANT 加列除外
MySQL 9.7.4 于 2026-10-20 发布。这版修的是 9.7.3 引入的一个副作用：为了修 B-tree 死锁而提高的记录大小估算精度，顺带把 CREATE TABLE / ALTER TABLE 的校验也收紧了，导致一部分在旧 LTS 上能正常建出来的表定义被拒或产生 warning。
现象
升级到 9.7.3 之后，原本跑得好好的 DDL 开始出问题：
CREATE TABLE语句的表定义被拒，或建表成功但产生 warning；ALTER TABLE同样受影响，报错或告警发生在校验阶段，而不是数据写入阶段；- 受影响的表定义在更早的 MySQL LTS 版本上是被接受的。
不是所有表都会踩到，取决于行大小估算是否刚好卡在边界上——列多、可变长列（VARCHAR、TEXT 前缀等）占比高的表更容易触发。
谁受影响
主要是从旧 LTS 升到 9.7.3 的环境，尤其是：
- 升级后需要重建表结构、加列、跑 schema migration 的应用；
- CI 里跑建表脚本、依赖
CREATE TABLE不回 warning 的流水线； - 把 9.7.3 当作兼容版本、直接沿用旧 DDL 的用户。
原有表不受影响，问题集中在新执行的 DDL 校验上。
9.7.4 改了什么
9.7.4 把校验行为拆成两条路径：
- 大部分 DDL 操作：恢复旧的（legacy）校验行为，也就是回到 9.7.3 之前的宽松判定，老表定义重新可以通过；
- 需要防止 B-tree 死锁的地方：保留 9.7.3 引入的精确行大小估算。这部分是死锁修复本身依赖的，不能退。
换句话说，精度只在真正需要它的路径上保留，其余地方回到原来的判定标准。
为什么 INSTANT 继续用严格计算
ALTER TABLE ... ALGORITHM=INSTANT 是例外：它仍然使用严格的行大小计算。
原因在于 INSTANT 算法不重建表，只改元数据，加列或改默认值时不会重写已有记录。大默认值会实际占用记录空间，如果估算不准，就可能出现记录放不下的情况，而这在 INSTANT 路径上没有回退余地。因此在 INSTANT 下保留精确估算，是为了安全处理大默认值。
如果某条 INSTANT DDL 在 9.7.4 上仍然被拒，说明它确实在这一项上过不了严格计算，需要换算法或调整表定义。
处置
- 优先升级到 9.7.4：这是官方给出的修复版本，大多数 DDL 恢复旧行为，升级后原先被拒的表定义可以直接重建。
- 暂时无法升级的：不要在 9.7.3 上继续执行被拒的 DDL，可以先在旧 LTS 上完成建表 / 改表，或调整表定义（减少列数、收窄可变长列长度）让行大小估算落回限制内，再切到新版本。
- 升级后如果只剩
ALTER TABLE ... ALGORITHM=INSTANT相关语句报错，属于预期内的严格校验，不要当作回退未生效。