MySQL 在线 ALTER TABLE 前怎么判断是否会重建表

判断 MySQL 的 ALTER TABLE 会不会重建表，不能只看“在线”两个字。先看这项操作是否支持 ALGORITHM=INSTANT；如果只能用 INPLACE，还要继续确认该操作是否会重组行数据。真正需要复制整张表的操作，再按磁盘空间、元数据锁和业务低峰安排窗口。

先把 ALTER 操作归类，再判断是否重建

生产变更前先执行下面两条信息查询，确认表不是临时表，且了解引擎、行数和现有索引。这里的行数是容量估计，不是 DDL 一定会处理的行数。

-- 先看引擎、分区和表的大致规模，避免把非 InnoDB 表套用同一结论
SHOW CREATE TABLE orders\G;
SELECT ENGINE, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'orders';

-- 再看索引，添加主键会重组聚簇索引，不能当作普通加二级索引
SHOW INDEX FROM orders;

可以按下面的经验表先做第一轮筛选。最终结果还受存储引擎、表属性、分区和语句组合影响，多个动作合并在一次 ALTER TABLE 中时，应按最重的那个动作规划。

用显式算法和 LOCK 把风险写进语句

不要让 ALGORITHM=DEFAULT 替你做上线决策。MySQL 8.4 对支持的列操作默认偏向 INSTANT，但“默认选择了什么”与“这次改动是否重建”不是同一个问题。想把不满足预期的操作挡在执行前，可以把最严格的能力写出来：

-- 只接受元数据级加列；不支持 INSTANT 时让语句失败，不自动降级
ALTER TABLE orders
  ADD COLUMN source_channel VARCHAR(32) NULL,
  ALGORITHM=INSTANT,
  LOCK=NONE;

如果业务要求允许并发写入，但操作本身属于在线重建，则使用 ALGORITHM=INPLACE, LOCK=NONE 只能表达“尽量不阻塞 DML”的要求，不能把重建变成元数据操作。比如添加主键、修改列类型、改变字符集，仍可能重组大量行。相反，LOCK=NONE 不被支持时应让它失败，别为了上线成功改成更宽松的锁。

还要单独留意元数据锁：在线 DDL 也可能在开始和结束阶段等待排他元数据锁。长事务、未提交的查询或另一个 DDL 都可能让“看起来在线”的语句卡住。

在克隆表试跑，观察 rows affected 和资源边界

对大表，官方建议先克隆结构并灌入少量数据，再执行候选 DDL。试跑不是精确预测线上耗时，而是确认语句能否使用目标算法、是否允许并发 DML，以及执行结果是否出现非零 rows affected。例如：

-- 用结构克隆隔离测试，不把实验动作打到生产表
CREATE TABLE orders_ddl_probe LIKE orders;
INSERT INTO orders_ddl_probe
  SELECT * FROM orders LIMIT 1000;

-- 显式要求 INPLACE 与非阻塞 DML；不满足条件就让 MySQL 返回错误
ALTER TABLE orders_ddl_probe
  ADD INDEX idx_orders_channel (source_channel),
  ALGORITHM=INPLACE,
  LOCK=NONE;

-- 实验结束后清理克隆表，避免把探针表当成业务数据
DROP TABLE orders_ddl_probe;

结果解读要分三层：返回算法不兼容错误，说明这条语句不能按预期路径执行；显示非零受影响行，说明它复制或重组了表数据；即使是零行，也不代表没有 IO，因为建索引仍要读取数据并写入索引页。试跑时同时记录执行时间、磁盘余量和复制延迟，才能估算线上窗口。

上线前的检查清单不要只写“在线”

变更单至少写清：目标表和存储引擎、语句中的每个动作、期望算法、允许的锁级别、预计数据量、可用临时空间、元数据锁等待上限、innodb_online_alter_log_max_size 风险、主从延迟阈值和回滚方案。字符集转换、主键变更、分区调整和 COPY 路径应按重建表处理。

如果 INSTANT 因即时列版本达到上限而失败，按错误提示安排一次真正的重建；不要反复重试同一条语句。大表改列类型或重建主键时，优先在副本或影子表验证，必要时采用分批迁移和切换，而不是把整段业务停在一条不可预估的 DDL 上。

常见问题

指定 INPLACE 就一定不会复制整张表吗？

不是。INPLACE 表示实现不走传统临时表复制路径，但添加主键、改列类型等仍会重组表数据，成本可能接近一次重建。

LOCK=NONE 能证明 ALTER TABLE 不会锁表吗？

不能。它主要约束并发 DML 的锁要求，开始和结束阶段仍可能等待元数据锁；MyISAM 等非 InnoDB 引擎也不能套用 InnoDB 的在线 DDL 结论。

rows affected 为 0 是否等于没有资源消耗？

不是。零行更适合说明没有复制行数据；建索引、读取数据页、写索引页和短暂锁等待仍会消耗资源。