必须用 KILL CONNECTION 终止持锁事务——KILL QUERY 对 Sleep 状态的 RUNNING 事务无效；需先查 INNODB_TRX 获取 TRX_MYSQL_THREAD_ID，确认 TRX_STATE='RUNNING' 和 TRX_ROWS_MODIFIED，再执行 KILL CONNECTION 并等待回滚完成。
必须先查 INNODB_TRX 定位真实事务，再用 KILL CONNECTION 终止连接——KILL QUERY 对持锁的 Sleep 连接完全无效。
为什么不能只看 SHOW PROCESSLIST
它只显示连接层状态，根本看不到事务是否还在持锁：Command = 'Sleep'、State = NULL、Time = 1800 的连接，可能正拿着 EXCLUSIVE 或 SHARED_WRITE MDL 锁，但 INFO 列为空，毫无提示。真正卡住 DDL 或关键 DML 的长事务，90% 都藏在这种“假空闲”连接里。
必须查 INFORMATION_SCHEMA.INNODB_TRX，盯住三个字段：TRX_STARTED（算持续秒数用 TIMESTAMPDIFF(SECOND, TRX_STARTED, NOW())）、TRX_STATE = 'RUNNING'（说明事务没结束）、TRX_MYSQL_THREAD_ID（这才是你要 KILL 的目标 ID，和 PROCESSLIST.ID 不一定相等）。
MySQL 5.7 中该用 KILL QUERY 还是 KILL CONNECTION
在 5.7 中：KILL QUERY 只中断当前语句，对已进入 Sleep 状态但事务仍 RUNNING 的连接毫无作用；KILL CONNECTION（或简写为 KILL）才会强制断连并触发事务回滚，从而释放 MDL 锁。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 如果线程
State是Locked、Waiting for table metadata lock或长时间Sleep且TRX_STATE = 'RUNNING'→ 必须用KILL CONNECTIONthread_id - 如果线程
State是Query且正在跑慢SELECT/UPDATE，应用还想复用连接 → 才考虑KILL QUERYthread_id - 严禁对
TRX_WAITING_TRX_ID IS NOT NULL（即正在等待锁）的事务执行KILL CONNECTION：这会让持锁者继续运行，堵得更死
执行前必须确认的三件事
直接 KILL 很快，但后果要兜得住：
- 确认该
TRX_MYSQL_THREAD_ID不属于关键批处理（如账务对账、日终结算），可查PROCESSLIST.USER和HOST判断来源 - 检查该连接是否由连接池（如 HikariCP）管理；若频繁
KILL，可能触发重连风暴，建议先KILL QUERY试探 10–20 秒，无变化再KILL CONNECTION - 优先用
KILL CONNECTIONthread_id（不是KILL QUERY），只有完整断连才能回滚事务、释放 MDL 锁
KILL 后锁还没释放？别急着重试
SHOW PROCESSLIST 显示状态为 Killed 是正常现象，不代表事务已结束。InnoDB 回滚耗时通常是正向操作的 3–5 倍：TRX_ROWS_MODIFIED 超过 10 万时，回滚可能卡在 Rolling back 状态几分钟，期间锁仍被占用。
务必再查 INNODB_TRX 中该事务的 TRX_OPERATION_STATE 是否为 rolling back，以及 TRX_ROWS_MODIFIED 估算剩余工作量。若发现 kill 后锁“一直不放”，优先确认是不是回滚本身太重，而不是命令没生效。
