应安全批量终止空闲超时的Sleep连接而非事务，先用SELECT CONCAT('KILL ',id,';')...WHERE command='Sleep' AND time>300生成语句，手动执行；设wait_timeout=300并调优应用连接池防复发。
不能直接“结束Sleep状态的事务”——因为Sleep状态本身不是事务，而是连接空闲时的状态；真正要处理的是连接，不是事务。 如果你看到大量 Command='Sleep' 的行，它们绝大多数没有活跃事务（INFORMATION_SCHEMA.INNODB_TRX 里查不到对应记录），强行 KILL 只是断开连接，不涉及事务回滚逻辑。只有当 Sleep 连接背后正卡在未提交事务（比如长事务后忘了 COMMIT 或 ROLLBACK）时，KILL 才会触发回滚——但这属于例外，不是常态。
怎么安全批量 KILL Sleep 连接（最常用场景）
生产环境最常遇到的是连接池配置不当或应用未 close() 导致数百个 Command='Sleep' 占满 max_connections。此时目标是快速释放连接，而非干预事务。
- 先确认哪些真该杀：加
AND time > 300（5分钟以上），避免误杀刚空闲的合法连接 - 用
SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE command = 'Sleep' AND time > 300;生成语句列表 - 复制结果，在 MySQL 客户端里一次性粘贴执行（注意：MySQL 不支持一条语句里写多个
KILL，必须分号分隔或逐条执行） - 别用
GROUP_CONCAT+PREPARE/EXECUTE自动执行——万一拼错语法或中间出错，整个批次就中断，且无法知道哪条失败
为什么 KILL 后有些连接还在 processlist 里显示 Sleep？
这是常见错觉，本质是两个原因：
-
KILL发出后，连接不会立即消失，MySQL 需等该连接下一次“检查点”（如等待下一个命令、超时触发、或客户端发包）才真正关闭。你立刻SHOW PROCESSLIST看到的仍是旧快照 - 如果客户端启用了自动重连（如某些 JDBC 驱动 +
autoReconnect=true），它可能在被 KILL 后几毫秒内又建了新连接，ID 变了但看起来“又回来了” - 真正验证是否生效：等 10 秒后再查，或用
SHOW GLOBAL STATUS LIKE 'Threads_connected';对比连接数变化
想防患于未然？别只靠手动 KILL
手动清 Sleep 是救火，不是方案。长期有效的方式是让 MySQL 自己回收：
- 设
wait_timeout = 300（5 分钟）并确认生效：SHOW GLOBAL VARIABLES LIKE 'wait_timeout';—— 注意别只看会话级变量 - 确保应用层连接池（如 HikariCP 的
idleTimeout）≤ MySQL 的wait_timeout，否则池子会自己驱逐连接再重建，反而加重负担 - 禁止在代码里裸写
Connection conn = dataSource.getConnection();后不close()；务必用 try-with-resources 或 finally 块保证释放 - 定期查
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 300;，揪出真正卡住的长事务，而不是只盯Command='Sleep'
最后提醒：KILL 是高危操作，尤其是对 User 是应用账号（非 root）的连接。如果不确定来源，先用 SELECT user, host, db, time FROM information_schema.processlist WHERE command = 'Sleep' AND time > 600; 筛一遍，人工核对是否属于已下线服务或测试脚本——误杀正在跑定时任务的连接，后果比 Sleep 本身更严重。
