大表DDL易锁表致业务阻塞，需用无锁/低锁方案：pt-osc（触发器同步）、gh-ost（binlog解析）、mysql 8.0+ INSTANT算法（仅限末尾加列等轻量操作），上线前须预跑、检查ROW格式binlog、避开高峰。
大表执行DDL操作容易引发长时间锁表，导致业务写入阻塞甚至超时。核心思路是避免直接对原表加锁，改用无锁或低锁方案完成结构变更。
为什么大表DDL会锁表
MySQL 5.6之前，大部分DDL操作（如ADD column、MODIFY COLUMN）需重建整表，期间对原表加排他锁（X锁），读写全被阻塞。即使5.7+支持部分ALgoRITHM=INPLACE，但涉及索引重建、字段类型变更等仍可能触发拷贝表逻辑，锁持续时间与数据量正相关。
主流在线DDL方案对比
pt-online-schema-change（pt-osc）
基于触发器实现实时数据同步：新建空表→拷贝存量数据→增量同步期间写原表→切换表名。全程原表可读写，但存在触发器开销和主从延迟放大风险。
gh-ost（gitHub Online Schema Change）
无触发器方案：通过binlog解析捕获变更，异步回放至影子表。资源占用更可控，对主库压力小，支持暂停/限速/安全退出，推荐新项目优先选用。
MySQL 8.0+原子DDL & INSTANT算法
对仅添加末尾列、重命名列等轻量操作，可启用INSTANT算法（ALTER table … ALGORITHM=INSTANT），毫秒级完成且不锁表。但不适用于索引增删、主键修改等场景。
上线前必须做的三件事
- 在从库或影子环境预跑DDL，确认执行耗时与空间占用（临时表+日志可能占原表2倍空间）
- 检查表是否启用了ROW格式binlog，gh-ost和pt-osc均依赖该格式获取变更
- 避开业务高峰，设置超时阈值（如gh-ost的–max-load、–critical-load参数），防止拖垮数据库负载
简单场景可直接用的兜底技巧
如果只是加一个允许NULL的字段且不涉及索引，MySQL 5.7+默认走INPLACE；8.0+确认满足INSTANT条件后，加字段可写成：
ALTER TABLE t1 ADD COLUMN c1 int NULL ALGORITHM=INSTANT;
执行前务必用SHOW CREATE TABLE核对当前存储引擎（仅InnoDB支持INSTANT）、行格式（需DYNAMIC或COMPRESSED），否则会自动降级为copy模式。
基本上就这些。关键不是选哪个工具，而是根据表大小、变更类型、运维习惯和容错要求做匹配。锁表风险可控，前提是别跳过评估和验证环节。