MySQL从库大量Sleep进程与主从同步无关，本质是应用连接池未合理管理连接：conn.close()仅归还连接至池中而非物理断开，若idleTimeout过长、maxIdle过大或未启用保活机制，将导致大量空闲连接长期维持Sleep状态；需协同调优连接池参数与wait_timeout（建议后者略大于前者），并排查应用连接泄漏。
MySQL Sleep连接不是“卡住”，而是“挂在那里等指令”
看到 SHOW PROCESSLIST 里一堆 State = Sleep 的连接，别急着 kill —— 这些连接本身没在执行 SQL，也没出错，只是客户端（比如你的 Java 应用、PHP 脚本或 Navicat）建连后没发新请求，MySQL 就让它歇着。它占着 Threads_connected 计数、吃内存、耗文件描述符，但不是故障状态。真正的问题是：为什么它们不走？谁让它们留这么久？
根本原因在应用层，不在主从同步或 MySQL 自身
从库上出现大量 Sleep 连接，和主从复制完全无关。I/O Thread 和 SQL Thread 的状态是 Waiting for master to send event 或 Slave has read all relay log，绝不会显示为 Sleep。所有 Sleep 都来自真实客户端连接，常见来源包括：
- Java 应用用了 HikariCP/Druid，但
max-lifetime≥wait_timeout，连接被 MySQL 主动断开后，池子仍当它是活的 - PHP 脚本用了
mysql_pconnect()或忘了调mysql_close()，页面结束连接还在 - Spring Boot + @Transactional 方法里提前
return，事务没提交，连接卡在线程绑定中不归还 - Navicat/DBeaver 等工具连上后最小化或休眠，几小时不动，连接就一直 Sleep
自动回收靠 wait_timeout + 连接池协同，不能只改一个
单独把 wait_timeout 从默认 28800 秒砍到 300 秒，反而会高频触发 MySQL server has gone away。必须让 MySQL 和连接池“说好话”：
-
wait_timeout和interactive_timeout必须同时设，且值一致（例如1200），否则非交互式连接（JDBC）可能不受控 - HikariCP 的
max-lifetime必须严格小于wait_timeout，建议差 30–60 秒（如 MySQL 设 1200，Hikari 设 1140） - 启用保活机制：
connection-test-query=SELECT 1+keepalive-time=30000（每 30 秒探活），比test-on-borrow更轻量 - 避免用
set global wait_timeout=120临时生效——配置要写进/etc/my.cnf的[mysqld]段并重启，否则实例重启就丢
代码里漏 close() 是最隐蔽的泄漏点
连接池不会替你兜底。哪怕配了 idle 清理，只要代码里有一次 conn.close() 没执行（比如异常分支没进 finally），那个连接就永远留在池里，直到 MySQL 强制断开。实操要点：
- 所有 JDBC 资源必须用
try-with-resources，不要手写finally——Connection、PreparedStatement、ResultSet全部包进去 - MyBatis 用户注意：
@Select流式查询（ResultHandler）或分页插件的count+list组合，容易因事务未结束导致连接滞留 - 检查日志里是否有高频
acquired connection却无对应released，这是泄漏铁证
真正难处理的不是 Sleep 本身，而是它背后混合了连接池配置、应用事务生命周期、MySQL 超时策略三层时间窗口。任何一个环节没对齐，就会在凌晨三点突然爆出 Too many connections。
