应使用MySQL的KILL命令而非kill-9：KILL是协议层指令，可安全回收连接、清理事务和释放锁；而kill-9强杀OS进程会绕过MySQL机制，导致事务未回滚、悬挂锁、临时表残留、主从复制中断甚至mysqld崩溃。
MySQL里怎么识别Sleep状态的长连接
直接查 information_schema.PROCESSLIST 或用 SHOW PROCESSLIST，重点看 Command 列为 Sleep、Time 值远大于业务合理阈值（比如 > 300 秒）的线程。注意：普通用户可能看不到其他用户的连接，需用具备 PROCESS 权限的账号（如 root）执行。
shell脚本里如何安全获取并kill指定Sleep连接
避免误杀的关键是加条件过滤——只 kill 满足「Sleep + 运行时间超阈值 + 非系统用户」的连接。示例核心逻辑：
mysql -u$USER -p$PASS -Nse "
SELECT CONCAT('KILL ', id, ';')
FROM information_schema.PROCESSLIST
WHERE Command = 'Sleep'
AND Time > 300
AND User NOT IN ('system user', 'root', 'monitor')
" | mysql -u$USER -p$PASS -N
-
-N禁用列名输出，避免 SQL 报错 -
-s启用静默模式，减少干扰字符 - 先生成
KILL xx;语句再管道执行，比在 MySQL 内直接循环更可控 - 务必排除
system user（复制线程）、root（可能正在运维）等关键用户
为什么不能直接用 kill -9 pid 来处理MySQL连接
MySQL 的连接进程（thread）和操作系统进程（OS pid）不是一一对应的。KILL 是 MySQL 协议层指令，由 mysqld 主动回收连接资源、清理事务、释放锁；而 kill -9 强杀 OS 进程会绕过 MySQL 内部机制，可能导致：
- 事务未回滚，留下悬挂锁（blocking lock）
- 临时表残留、内存未释放
- 主从复制中断或位点错乱（尤其在 binlog_format=STATEMENT 时）
- mysqld 出现异常日志甚至 crash
实际部署时最容易被忽略的三个点
脚本跑通不等于能上线，这几个细节常导致半夜告警：
- MySQL 客户端命令路径没写全（比如用
/usr/bin/mysql而非裸mysql），crontab 环境下 PATH 不包含 /usr/local/bin - 密码明文写在脚本里，权限设成 644 就等于公开泄露，至少得
chmod 600+ 用配置文件（~/.my.cnf）存凭证 - 没加锁机制，多个实例并发运行脚本，可能重复 kill 同一个连接，触发 MySQL 的
Unknown thread id报错，虽不致命但干扰监控判断
