mysql 8.0 不会自动杀死阻塞 ddl 的长事务，仅提供更精准识别和安全干预接口；需通过 information_schema.innodb_trx 查 trx_started 时间戳定位长事务，并用 kill 终止线程。
MySQL 8.0 本身不会自动杀死阻塞 DDL 的长事务 —— 这是常见误解。它只提供更精准的识别手段和更安全的干预接口，是否终止、何时终止，仍需人工或外部脚本决策。
为什么 SHOW PROCESSLIST 看不到真正“卡住 DDL”的事务
DDL（如 ALTER TABLE）被阻塞时，执行 DDL 的线程常处于 Waiting for table metadata lock 状态，但真正持有元数据锁（MDL）的线程可能早已“静默”：它没在跑查询，trx_state = 'RUNNING' 也不一定成立，甚至 COMMAND 显示为 Sleep。仅靠 SHOW PROCESSLIST 容易漏掉罪魁祸首。
必须查 INFORMATION_SCHEMA.INNODB_TRX，重点看：
-
trx_started时间戳 —— 比如超过 60 秒未更新，就是高风险长事务 -
trx_mysql_thread_id—— 对应PROCESSLIST.ID，用于后续 KILL - 避免只依赖
trx_state = 'RUNNING'，它只表示事务未提交，不反映活跃度
innodb_lock_wait_timeout 不影响 DDL 阻塞
这个参数只控制普通 DML（如 UPDATE、SELECT ... FOR UPDATE）等待行锁的超时，对 DDL 所需的元数据锁（MDL）完全无效。DDL 阻塞会一直挂起，直到持有锁的事务提交或被主动终止。
你无法通过调大 innodb_lock_wait_timeout 让 DDL “自动超时失败”，也不能靠它触发自动清理。
如何用动态变量实现“半自动”长事务干预
MySQL 8.0 允许运行时修改部分系统变量，配合定时任务可构建轻量级防护逻辑：
示例：用 SET PERSIST 设置一个运维标记变量（需 SUPER 权限）
SET PERSIST ddl_safety_mode = 'ON';
再写一个简单脚本（如每分钟 cron）检查并处理：
- 查
INNODB_TRX中trx_started - 关联
PROCESSLIST获取USER和HOST，排除 DBA 账户（如'dba'@'%'） - 确认后执行
KILL <thread_id></thread_id>（不是KILL QUERY） - 记录日志，含
trx_query前缀（用SUBSTRING_INDEX(trx_query,' ', 4)）便于回溯
关键点：
- KILL 是唯一能真正结束事务的方式；KILL QUERY 只中断当前语句，事务仍开着，锁还在
- 不建议在高峰期直接 KILL 核心业务线程，优先用 SELECT ... FOR UPDATE NOWAIT 或应用层加超时兜底
- innodb_ddl_threads 等并行参数不能解决阻塞问题，它们只加速 DDL 自身执行，不缓解锁竞争
真正容易被忽略的点
很多团队以为升级到 MySQL 8.0 就“自动安全”了，但实际生产中：DDL 阻塞往往源于应用端未正确关闭事务（比如 ORM 开启了事务但忘了 commit/rollback），或者监控脚本长期持有只读事务查询元数据。这类问题不会报错，但会让后续所有 DDL 排队。比配置参数更重要的是，在应用侧强制事务超时（如 Spring 的 @Transactional(timeout = 30)）和定期巡检 INNODB_TRX 的机制。
