mysql 5.6+ 添加字段仍会卡住业务，根本原因是mdl写锁阻塞所有新读写请求；即使空表加int字段也会全程排他锁，且algorithm=inplace和lock=none受长事务、not null无默认值、缺失主键等影响而降级锁级别。
MySQL 5.6+ 添加字段为什么还会卡住业务？
不是“加字段”本身慢，而是它触发了元数据锁（MDL）写锁，所有后续的读写请求都得排队等这个DDL完成。哪怕你只是给一个空表加个 INT 字段，在 MySQL 5.6 中仍会全程排他锁（LOCK=EXCLUSIVE），SELECT、INSERT 全部挂起——这不是超时，是真·阻塞。
关键点在于：MDL 写锁会阻塞所有新进的 MDL 读锁，而每个普通查询/更新都必须先拿到读锁才能执行。一旦 DDL 卡在某个环节（比如遇到长事务没提交），整个表就“假死”了。
- 查当前是否有长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60 - 看谁占着 MDL：
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_NAME = 'your_table' AND LOCK_STATUS = 'PENDING' - 别只盯着
SHOW PROCESSLIST，它不显示 MDL 等待细节
ALGORITHM=INPLACE 和 LOCK=NONE 不是万能的
MySQL 5.7+ 支持 ALGORITHM=INPLACE，但是否真正“零阻塞”，取决于字段定义和表结构：
- 加
NULL列 + 有默认值 → 大概率LOCK=NONE（推荐） - 加
NOT NULL列且无默认值 → 必须扫描全表填空值 → 退化为COPY算法 → 锁表 - 表没有主键或唯一索引 → InnoDB 用隐式聚簇索引 → DDL 更容易触发全表扫描和锁升级
- 执行时若存在未提交事务（哪怕只是
SELECT ... FOR UPDATE），LOCK=NONE也会失败并回退到更重的锁级别
所以命令不能只写 ALTER TABLE t ADD COLUMN c INT NULL DEFAULT 0, ALGORITHM=INPLACE, LOCK=NONE，还得确认执行后 SHOW PROCESSLIST 里没有 Waiting for table metadata lock 状态。
大表加字段必须绕开原生 ALTER 的三种场景
当表行数超过百万、或业务 SLA 要求“完全不可感知”时，原生 DDL 就不够用了。这时候要主动降级信任：
- pt-osc：Percona Toolkit 的经典方案，通过影子表 + 触发器同步数据，全程不锁原表；缺点是触发器带来额外写开销，且对高 QPS 写入敏感
-
gh-ost：GitHub 开源方案，用 binlog 解析替代触发器，无锁、无触发器、支持暂停/限速；但要求开启
binlog_format=ROW且不能有ENUM或SET类型字段 - 分阶段双写：应用层同时写新旧两张表，等数据追平后切读流量，最后删旧字段；适合字段语义清晰、可灰度的业务，但开发成本最高
注意：gh-ost 在 MySQL 8.0.29+ 对 JSON 字段支持仍有坑，执行前务必在测试环境跑通 --dry-run。
最容易被忽略的两个前置检查点
再稳妥的方案，也救不了没做基础检查的操作：
- 确认表引擎是
InnoDB——MyISAM表加字段永远锁表，且不支持ALGORITHM=INPLACE - 检查
innodb_online_alter_log_max_size值 —— 默认 128MB，如果加字段涉及大量二级索引重建，可能因日志空间不足被迫中止并回滚，导致锁持续更久
真正决定加字段是否“安全”的，从来不是命令多漂亮，而是你有没有在执行前看清这张表的锁依赖链、长事务状态和索引健康度。DDL 操作没有“试错成本低”这回事，一次误操作，可能就是几十分钟的业务抖动。
