先说一个很残酷但真实的结论：MySQL 里对大表执行 ALTER TABLE，从来就不是“改个结构”那么简单。它几乎一定会触发全表重建、锁表、IO 风暴，甚至可能引发主从延迟、连接池耗尽，最终导致服务雪崩——这些不是理论风险，而是线上高频事故，见过太多团队因此翻车。
那么，为什么 ALTER TABLE 在大表上这么容易锁住读写？关键在于其背后的执行算法。
ALTER TABLE 在大表上为何会锁表或阻塞读写？
MySQL 的 ALTER TABLE 可不是“改个字段名”这么简单，它本质上是元数据变更加物理结构的双重调整。对于千万级的大表，绝大多数操作仍然要使用 COPY 算法——尤其是在 MySQL 5.6 之前，或者某些特定字段类型变更的场景下。
具体来看看几个常见的“雷区”：
- ADD COLUMN 带 NOT NULL 但未给默认值：InnoDB 为了给每一行都填充一个值，必须触发全表扫描加行更新，此时锁级别会直接升级到 SHARED 甚至更严格。这不是小动作，相当于把整个表从头到尾改了一遍。
- MODIFY COLUMN 即使只改默认值：使用 MODIFY 或 CHANGE 命令时，MySQL 的处理方式就是重建一张新表，哪怕这个改动仅仅涉及 .frm 文件都能轻松搞定。它的反应就是如此“过激”。
- 即使是 ALGORITHM=INPLACE：看起来是原地操作，但只要涉及索引重建、页分裂、B+树重排，它仍然会持有 MDL（metadata lock）。而 MDL 一旦锁住，后续所有 DDL 和 DML 都得排队，一个都别想跑。
所以核心问题很清楚：大部分 ALTER TABLE 操作全程持有 MDL 写锁和表级锁，阻塞所有读写请求；即便使用了 INPLACE 模式，MDL 的短暂持有在高并发或长事务下仍然会导致排队等待，最终引发雪崩。
为何 Online DDL 也不能完全放心？
MySQL 5.7 引入的 ALGORITHM=INPLACE 和 LOCK=NONE 选项，确实是大表变更的救星，大幅降低了影响范围。但请注意，它有着严格的前提和隐性代价——绝不是万能药。
- 真正无锁支持的操作很有限：比如 ADD COLUMN，必须满足类型兼容、允许 NULL、有 DEFAULT 值这些条件。一旦加上 NOT NULL 且没有默认值，系统会立刻退化为锁表模式，之前的“无锁”承诺瞬间作废。
- LOCK=NONE 不等于零影响：高并发下，所有 DML 仍然要排队争抢 MDL。你会在监控里看到大量慢查询堆积，状态栏
Waiting for table metadata lock直线飙升。服务延迟和连接耗尽的风险依然存在。 - 主从延迟问题避不开：主库上执行 DDL 的同时，从库必须重放这个事件。只要 DDL 耗时稍长，从库的延迟可能从秒级直接跳到分钟级，直接影响读取一致性和备份恢复点。
- 磁盘和日志压力暴增：ALTER TABLE 过程中产生的临时文件、redo log、binlog 都可能惊人增长。如果磁盘空间不足，或者 IO 饱和，拖慢的不只是这张表，而是整个库的所有操作。
真实线上最容易踩的三个坑
不是“会不会出问题”，而是“什么时候出、怎么爆得最狠”。下面这三个场景，基本是线上事故的高频阵地：
- 误判版本行为：这是最常见的。假设你的表有千万级数据，你在 MySQL 5.7 上执行一条
ALTER TABLE ... ADD COLUMN xxx INT NOT NULL，心里想着“用 INPLACE 模式应该很快”，结果命令一执行，整整卡住了 20 分钟。为什么？因为 NOT NULL 但没有默认值，MySQL 强制退回到了 COPY 模式。你以为是快的，实际上是全表重建。 - 忽略隐式锁竞争：DDL 执行期间，应用层可不会停下脚步。大量
INSERT ... ON DUPLICATE KEY UPDATE请求持续涌入，每一个都得抢 MDL 锁。结果就是 DDL 和这些 DML 在锁上死磕，连接池被快速耗尽，最终报错Too many connections。你眼睁睁看着服务崩溃，却连杀掉进程都来不及。 - 低估日志压力：一场 ALTER 操作下来，产生的 binlog 可能高达数个 GB。这对于从库来说几乎是毁灭性的——IO 立刻被打满，Seconds_Behind_Master 从秒级跳到分钟级，甚至触发 binlog 文件轮转失败，连带阻塞所有写入。从库一旦垮掉，整个读链路就断了。
所以，不建议在大表上频繁执行 ALTER TABLE 的真正原因，从来不是因为“执行一条 SQL”这个动作本身有多难，而是从一开始就要预判它用的是什么锁类型、会在哪个环节卡住、对从库和磁盘的压力有多大。这些监控和预判的逻辑（比如实时查看 INFORMATION_SCHEMA.INNODB_TRX、盯紧 PROCESSLIST 的状态、跟踪从库的 Seconds_Behind_Master 波动），比那条 ALTER 语句本身重要得多。
