慢SQL导致连接耗尽，因其使连接长时间处于Query状态无法释放，叠加连接池重试会持续申请新连接，迅速占满max_connections；须同步限制单用户连接数（如ALTER USER ... MAX_USER_CONNECTIONS 12）和设置wait_timeout=120，并确保连接池参数与之匹配。
为什么慢SQL会直接导致连接耗尽
慢SQL本身不“占用多个连接”，但它会让一个连接长时间卡在 Command = Query 状态，无法释放。当应用层使用连接池（如 HikariCP、Druid），且配置了较激进的重试或超时策略时，大量请求会持续尝试获取新连接——而每个新连接都得排队等前面那个慢SQL结束。结果就是：连接数快速涨到 max_connections 上限，后续所有请求直接报错 ERROR 1040 (HY000): Too many connections。
必须同时限制单用户连接数 + 设置 wait_timeout
只调大全局 max_connections 是无效的，反而掩盖问题。真正要做的，是把风险隔离到账号粒度，并让空闲连接自动退出：
-
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 12;—— 把该账号能建的连接上限压到业务真实并发量附近，避免一个异常服务拖垮整库 -
SET PERSIST wait_timeout = 120;—— 让空闲超过 2 分钟的连接自动断开，防止慢SQL执行完后连接还挂着不动（interactive_timeout同理，设为相同值） - 注意：这两个值必须匹配连接池的
idleTimeout和maxLifetime，否则池子会主动驱逐连接，但 MySQL 还没感知到，造成状态不一致
如何验证慢SQL是否真被“关进笼子”
光看 SHOW PROCESSLIST 没用，它显示的是历史快照，无法反映连接拒绝行为。要确认防护生效，得做两件事：
- 查限制是否写入：执行
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';，返回值必须是明确数字（不能是0或NULL） - 手动触发拒绝：用该账号反复执行
mysql -u app_user -p -e "SELECT SLEEP(10);"，第max_user_connections + 1次应立刻报错ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections'
连接池配置不匹配是最隐蔽的爆点
很多团队配了 MAX_USER_CONNECTIONS 8，却把 HikariCP 的 maximumPoolSize=20，等于主动埋雷。更麻烦的是 PHP PDO 这类默认不复用连接的场景：一个脚本里循环 new PDO() 十几次，几秒内就打满配额。
关键检查点：
- 连接池最大值 ≤ 对应账号的
max_user_connections - 连接池的
connectionTimeout要小于 MySQL 的connect_timeout（默认 10 秒），否则应用会先超时，根本等不到 MySQL 拒绝连接的错误码 - 应用日志里如果频繁出现
ER_CON_COUNT_ERROR（错误码 1226），说明限制已起效，但业务没做降级或熔断
真正容易被忽略的是：限制只在新建连接时校验，旧连接不会被踢。所以慢SQL跑完之后，连接还在 Sleep，新请求照样连不上——这不是配置失效，而是资源没腾出来，得靠 wait_timeout 或连接池自己回收。
