大表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条件后，加字段可写成：

git-pr-workflows-pr-enhance

你是一位 PR 优化专家，专注于创建高质量、便于高效代码审查的 Pull Request。生成全面的 PR 描述，自动化审查流程，

下载

ALTER TABLE t1 ADD COLUMN c1 INT NULL ALGORITHM=INSTANT;

执行前务必用SHOW CREATE TABLE核对当前存储引擎（仅InnoDB支持INSTANT）、行格式（需DYNAMIC或COMPRESSED），否则会自动降级为COPY模式。

基本上就这些。关键不是选哪个工具，而是根据表大小、变更类型、运维习惯和容错要求做匹配。锁表风险可控，前提是别跳过评估和验证环节。