MySQL连接断开后锁未释放需手动干预：先查PROCESSLIST中COMMAND非Sleep或TIME>300且INFO为空、STATE异常的连接，再结合INNODB_TRX中TRX_STATE='RUNNING'且TRX_QUERY IS NULL、TRX_STARTED超时的记录，确认后执行KILL CONNECTION终止对应线程以回滚事务释放锁。
MySQL 连接断开后锁没释放，怎么办？
MySQL 不会自动清理因网络中断残留的连接持有的锁，这是真实存在的问题。客户端断开后，wait_timeout 或 interactive_timeout 机制只负责关闭空闲连接，但若连接在事务中突然断开（比如 TCP RST、NAT 超时、代理中断），事务不会自动回滚，锁会一直挂着，直到连接被服务端主动 kill 或超时触发 innodb_lock_wait_timeout（仅影响新等待者，不释放已有锁）。
怎么快速发现并干掉僵尸连接？
先确认哪些连接是“活着但已失联”的：它们状态是 Sleep 或 Locked，但 Time 值远大于你的业务正常响应时间（比如 > 300 秒），且没有对应活跃客户端 IP 或进程。关键命令：
SELECT id, user, host, db, command, time, state, info FROM information_schema.processlist WHERE command != 'Sleep' OR time > 300;
重点看 info 列是否为 NULL 或空，且 state 是 Locked 或 Updating；再结合 SHOW ENGINE INNODB STATUS\G 中的 TRANSACTIONS 部分，找 TRX_STATE: RUNNING 但 TRX_MYSQL_THREAD_ID 对应的连接已不可达。
- 用
KILL [connection_id]手动终止，不是KILL QUERY—— 后者只停当前语句，不回滚事务 - 别依赖
wait_timeout自动清理：它只对command = 'Sleep'生效，事务中的连接不会进入 Sleep 状态 - 生产环境建议加监控：定期查
processlist+INNODB_TRX视图，对trx_started时间过久且无活跃 client 的事务告警
如何从源头减少这类问题？
应用层比数据库层更容易控制连接生命周期。核心是让连接断开时事务能确定性结束：
- 所有数据库操作必须设明确的
timeout：比如 JDBC 的socketTimeout和queryTimeout，避免线程卡死导致连接滞留 - 禁用长事务：业务逻辑里不要跨 HTTP 请求或用户交互持有一个事务；用
SET innodb_lock_wait_timeout = 10缩短锁等待上限（单位秒） - 连接池必须开启
testOnBorrow或validationQuery（如SELECT 1），并配置合理的minEvictableIdleTimeMillis，及时剔除失效连接 - MySQL 侧可调低
net_read_timeout和net_write_timeout（默认 30 秒），让异常连接更快被识别为“读写超时”而中断
为什么 innodb_deadlock_detect = ON 解不了这个问题？
死锁检测只处理两个及以上事务互相等待的循环依赖，而网络中断导致的单事务持锁不释放，不属于死锁范畴——它没有等待者，只是“没人管”。所以即使开了死锁检测，也不会触发自动 rollback。
真正起作用的是连接层的超时机制和应用层的防御性设计。最容易被忽略的是：很多 ORM 框架默认不设置 query timeout，连接池也常关 validation，结果就是连接看着“在线”，锁却挂了十几分钟没人收。
