MySQL ALTER TABLE 默认锁表因5.6前全程写锁，5.6+未显式指定ALGORITHM=INPLACE和LOCK=NONE时仍可能拷表；需结合表结构、参数控制及负载评估规避阻塞。
MySQL ALTER TABLE 为什么一执行就锁表
默认情况下，alter table 在 mysql 5.6 之前会全程加写锁，dml（insert/update/delete）全部阻塞；5.6+ 虽支持部分 algorithm=inplace 操作，但只要没显式指定，仍可能退化为拷表（copy），锁表时间取决于表大小。
常见错误现象：SHOW PROCESSLIST 里看到状态是 Waiting for table metadata lock，或业务报错 Lock wait timeout exceeded。
- 不是所有 DDL 都能在线：比如给大表加全文索引、修改
TEXT列类型、或在无主键表上加主键，MySQL 仍强制用COPY算法 - 即使支持
INPLACE，也分「仅元数据变更」和「需重建二级索引」两类——后者仍要扫描全表，只是不锁 DML - 务必用
SHOW CREATE TABLE确认表是否含主键、是否使用innodb_file_per_table，这两点直接影响能否真正在线
如何强制走 Online DDL 流程
MySQL 5.6+ 后，必须显式控制 ALGORITHM 和 LOCK 两个参数，否则优化器可能自行降级。重点不是“能不能”，而是“你有没有告诉它别锁”。
实操建议：
- 优先尝试：
ALTER TABLE t1 ADD COLUMN c1 INT, ALGORITHM=INPLACE, LOCK=NONE;——LOCK=NONE是硬性要求，缺了就可能锁表 - 若报错
ALGORITHM=INPLACE is not supported，说明操作不支持完全无锁，可降级为LOCK=SHARED（允许读，阻塞写），比默认的LOCK=DEFAULT（等价于LOCK=EXCLUSIVE）更安全 - 对 5.7+，可用
pt-online-schema-change作为兜底：它用触发器+影子表模拟在线，但会增加主从延迟和磁盘压力，不是银弹
可视化工具（如 Navicat / DBeaver）里改表结构的风险
这些工具默认生成的 DDL 很少带 ALGORITHM 和 LOCK，点一下“保存修改”，背后跑的是裸 ALTER TABLE，等于直接把锁表风险交给 GUI 承担。
使用场景中容易被忽略的点：
- Navicat 的「设计表」界面改字段类型时，勾选“允许空值”或“设为自增”都可能触发
COPY，它不会提醒你 - DBeaver 的“编辑列”右键菜单里，如果表有外键或全文索引，它连
ALGORITHM参数都不给你填的位置 - 正确做法：关掉可视化编辑，切到 SQL 编辑器，手写带
ALGORITHM和LOCK的语句，再执行
低峰期 ≠ 安全区，得看真实负载特征
定个凌晨 2 点执行，不代表安全——如果业务有定时归档任务、ETL 拉取、或下游服务在那个点批量重试，照样可能撞上高 IO 或连接数峰值。
判断依据不能靠“感觉”：
- 查
SHOW GLOBAL STATUS LIKE 'Threads_running';，持续高于 30 就谨慎 - 看
iotop -a或pt-iostat，确认磁盘 await 和 %util 是否已接近阈值 - 检查慢查询日志里最近 1 小时有没有大量
Waiting for table metadata lock，有说明元数据锁竞争本就激烈
真正难的不是选哪个参数，是搞清你的表在那一刻到底被谁读着、谁写着、谁等着——锁从来不是孤立事件，是并发关系的快照。
