java应用连接mysql时大表ddl锁表停顿的本质是mysql执行机制与业务调用时机共同作用的结果，关键在于执行ddl的时机、方式及前提条件，而非java代码本身；应优先使用mysql 8.0+原生online ddl（如algorithm=instant），满足字段末尾添加、null/default值、dynamic行格式等条件，千万级表必须用pt-osc工具配合java调用与进度监听，同时收紧连接池配置、严格变更窗口隔离、实现失败熔断，并严禁@transactional包裹ddl、多线程并发执行、定时任务轮询及hibernate自动ddl等伪优化。
Java 应用连接 MySQL 时，大表 DDL 引发的锁表停顿，本质不是 Java 的问题，而是 MySQL 执行机制与业务调用时机共同作用的结果。关键不在“Java 怎么写”，而在于“什么时候、用什么方式、在什么前提下执行 DDL”。Java 层要做的，是配合数据库策略做兜底和协同，而不是试图靠代码绕过底层锁机制。
优先用 MySQL 原生 Online DDL（8.0+ 最优）
MySQL 8.0 对 ADD COLUMN 等操作默认走 ALGORITHM=INPLACE，多数场景已能秒级完成，几乎不阻塞读写。但必须满足几个硬条件：
- 字段加在末尾且为 NULL 或带 DEFAULT 值（如
ADD COLUMN status TINYINT DEFAULT 0） - 表格式为 Dynamic（
SHOW CREATE TABLE t中确认ROW_FORMAT=DYNAMIC） - 显式指定
ALGORITHM=INSTANT（仅限加列/改默认值/重命名列），锁持有时间可压缩到毫秒级 - 执行前检查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started ，有就协调业务方清理
千万级以上表，别信“默认不锁”，必须用 pt-osc
哪怕 MySQL 8.0，只要涉及 NOT NULL 无默认值、修改列类型、加索引等操作，仍可能退化为 COPY 模式，锁表几十分钟。此时 Java 应用需配合 pt-online-schema-change 工具，而非直接发 ALTER：
- Java 不直接执行 DDL，而是调用 Shell 命令触发 pt-osc（如
pt-online-schema-change --alter "ADD COLUMN remark TEXT" D=test,t=user --execute） - 通过监听 pt-osc 日志或检查
_user_new临时表是否存在，判断迁移进度 - 变更期间允许 Java 正常读写原表，pt-osc 自动通过触发器同步增量变更
- 务必关闭 autocommit=false 的 ORM 隐式事务（如 MyBatis 默认开启），避免 SELECT 不提交导致 MDL 锁堆积
Java 层必须做的三件事
不是写 SQL，而是管住连接、控好时机、留好退路：
-
连接池配置收紧：HikariCP 中设
connection-timeout=3000、max-lifetime=1800000，避免 DDL 卡住后连接长期挂起 - 变更窗口严格隔离：只在低峰期（如凌晨 2–4 点）执行，Java 服务端可通过配置中心开关控制是否允许 DDL 调用
-
失败快速熔断：封装 DDL 执行逻辑，捕获
ERROR 1105 (HY000): Waiting for table metadata lock后立即退出，不重试，记录告警并通知 DBA
绝对要避开的 Java “伪优化”
这些看似聪明的做法，反而放大风险：
- 在业务代码里用
@Transactional包裹 DDL —— Spring 事务会自动开启隐式事务，让 MDL 锁等待雪上加霜 - 用多线程并发执行多个小表 DDL —— 表越多，MDL 锁竞争越激烈，容易引发连锁阻塞
- 把 DDL 当普通 SQL 放进定时任务轮询执行 —— 缺乏人工确认和监控，失败后无感知
- 依赖 Hibernate
hibernate.hbm2ddl.auto=update上线自动建字段 —— 生产禁用，无法控制锁行为和执行时机
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
