MySQL 修改大表列类型前怎么估算复制和回滚边界

给 MySQL 大表修改列类型，最容易误判的是把 ALTER TABLE 当成“几秒钟的元数据操作”。以 InnoDB 为例，MySQL 8.4 对列数据类型变更只支持 ALGORITHM=COPY：需要重建表，执行期间不能并发 DML，磁盘还要容纳临时副本。也就是说，变更窗口的核心不是预估一个漂亮的秒数，而是先算清复制、停写、空间和回退四条边界。

先判断列类型变更会落到哪种 DDL 算法

MySQL 8.4 的 ALGORITHM=INSTANT 只改数据字典，INPLACE 可能原地重建但通常保留 DML；而修改列数据类型不属于这两类。官方在线 DDL 表把它列为“不支持 Instant、不支持 In Place、会重建表、不允许并发 DML”。因此下面这类语句的重点不是强行追求 LOCK=NONE，而是让计划明确暴露 COPY 边界：

-- 先在变更单里固定目标类型与算法，避免默认算法悄悄扩大风险
ALTER TABLE order_archive
  MODIFY COLUMN amount BIGINT NOT NULL,
  ALGORITHM=COPY,
  LOCK=SHARED;

LOCK=SHARED 表示允许查询、拒绝并发写入；它不能把 COPY 变成在线写入。若业务不能接受停写，应重新设计迁移，例如新增兼容列、双写、分批回填，再在最后做短暂切换，而不是给同一条语句换一个锁参数。

用数据量、索引和磁盘余量估算变更窗口

不要用“表有一亿行，所以大约几分钟”这种估算。更稳的做法是先在与生产结构相近的副本上测出 COPY 吞吐，再按下面的分解留余量：

可以把初始公式写成：执行窗口 ≈ 待复制数据量 ÷ 实测吞吐 + 锁等待 + 收尾余量。磁盘预算则至少覆盖“现有表与索引 + COPY 临时空间 + 变更期间日志增长”；共享表空间还要注意释放空间的行为，不要只看操作系统当前可用空间。

正式执行前先记录表定义、行数、数据与索引体积、最长事务和副本延迟。下面的检查只读，不会替你判断业务能否停写：

-- 用元数据建立变更前基线，数值应保存到变更单
SELECT table_name, table_rows, data_length, index_length
FROM information_schema.tables
WHERE table_schema = 'shop' AND table_name = 'order_archive';

-- 确认目标列和索引依赖，避免转换后才发现应用仍按旧范围写入
SHOW CREATE TABLE shop.order_archive;
SHOW INDEX FROM shop.order_archive;

把源库、副本和回退方案分开计算

MySQL 复制默认是异步的，副本按自己的速度读取并执行源库二进制日志。源库的 COPY 结束，不代表所有副本已经可读：副本可能仍在等待 DDL、应用积累的日志，或因目标类型无法接收某些值而停止 SQL 线程。变更前应分别设定源库停写窗口和副本最大可接受延迟，观察的是“副本能否恢复到基线”，不是只看源库语句返回成功。

列类型收窄尤其要检查实际值范围、默认值、索引和应用序列化格式。扩大类型也不等于没有风险：副本表定义不同、触发器不同或应用仍依赖旧类型时，复制可能成功但业务读写语义已变。遇到类型转换不兼容，应先在副本或临时表上做数据扫描和抽样校验，别把复制当成数据兼容测试。

回退要分三个时点：

• 执行前：取消语句、恢复应用开关或回到备份，是最便宜的回退。
• 执行中：只允许在确认当前阶段可安全终止时停止；不要指望客户端发送 ROLLBACK 就撤销一条正在运行的 DDL。
• 成功提交后：ROLLBACK 不能把表类型改回去，应使用备份恢复、反向 ALTER TABLE 或兼容期内的新列迁移。

常见问题

为什么不能给修改列类型加 LOCK=NONE？

因为 InnoDB 的这类操作只支持 COPY，必须重建表且不允许并发 DML。LOCK=NONE 不是能力开关，显式指定只会让不支持的计划失败。

ALTER TABLE 失败后一定能用 ROLLBACK 恢复吗？

用户事务里的 ROLLBACK 不能撤销 ALTER TABLE。InnoDB 原子 DDL 能保证数据字典、存储引擎操作和二进制日志在崩溃恢复时保持一致，但它不是把 DDL 纳入业务事务。

复制延迟达到多少就应该停止变更？

没有通用秒数，应按业务读流量、故障切换要求和副本追赶吞吐设阈值。变更单应写出最大延迟和恢复时间，而不是套一个固定数字。

扩大列类型是不是可以不做备份？

不建议。扩大类型通常少了截断风险，但 COPY 仍可能占用大量空间、拖慢副本或暴露应用兼容问题，备份点和反向路径仍要保留。

真正可执行的结论是：先确认算法，再用实测吞吐估时间，用额外空间和副本延迟约束窗口，最后把“崩溃可恢复”和“业务可回退”分别写进变更单。这样即使变更不能在线完成，也能尽早知道应该改成双写迁移，还是安排一次明确的停写窗口。