快速缓解 MySQL “Too many connections” 的止血操作是：先 SET GLOBAL max_connections = 200（需 SUPER 权限），再 KILL Sleep 超 60 秒的闲置连接；根本解法是排查应用层连接泄漏、慢 SQL 和事务未提交问题，并合理配置 HikariCP 与 MySQL 超时参数对齐。
MySQL 报 Too many connections 怎么快速缓解
立刻生效的止血操作只有两个：SET GLOBAL max_connections = 200（需 SUPER 权限）和杀掉闲置连接。但别急着调高 max_connections，它只是把问题往后推——真正堵在门口的是应用层没释放的连接。先执行 SHOW PROCESSLIST，重点看 Command 列为 Sleep 且 Time 超过 60 秒的连接，用 KILL [id] 清理；再检查应用日志里是否频繁出现 Connection refused 或超时重试，这说明连接池已打满但还在拼命建新连。
Java 应用里 HikariCP 连接池关键参数怎么设
HikariCP 不是越大越好，盲目设 maximumPoolSize=100 可能压垮 MySQL。真实值要按数据库负载反推：单台 MySQL 实例建议 maximumPoolSize ≤ max_connections × 0.7，再除以应用实例数。比如 MySQL 的 max_connections=200，部署了 4 个 Java 实例，那每个实例的 maximumPoolSize 设成 35 比较安全。connectionTimeout 建议不超 3000ms，避免线程卡死；idleTimeout 设为 600000（10 分钟），防止空闲连接占着坑不走；必须开 leakDetectionThreshold=60000，否则连接泄漏会悄无声息吃光池子。
为什么加了连接池还是扛不住突发流量
常见原因不是池子小，而是池子被“锁死”了：
- SQL 执行慢（如没走索引的
SELECT * FROM orders WHERE user_id = ?），连接被长期占用 - 事务没及时提交或回滚，
autocommit=false下一个连接就卡在事务里 - 连接获取后没 close，HikariCP 的
close()是空操作，真正释放靠return到池子，但 if-else 分支漏写了try-with-resources或finally块
SHOW ENGINE INNODB STATUS 里的 TRANSACTIONS 部分，看是否有长时间未提交的事务；用 SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 30 定位滞留连接来源。MySQL 侧哪些配置影响连接池实效性
wait_timeout 和 interactive_timeout 必须和连接池的 idleTimeout 对齐，否则池子里的空闲连接会被 MySQL 主动断开，下次取用时抛 Communications link failure。建议设成比 idleTimeout 大 30 秒，例如池子设 600 秒，MySQL 就设 wait_timeout = 630。max_connect_errors 如果被触发，会导致 IP 被锁，突发流量下容易误伤，可临时设大点（如 100）；connect_timeout 建议保持默认 10 秒，太短会让偶发网络抖动直接断连，太长又拖慢失败感知。
连接池不是万能胶，它只管“借还”，不管“快慢”。真正决定吞吐上限的，是单条 SQL 耗时、事务粒度、以及应用是否在非必要场景里开了事务。线上出问题时，先看慢查询日志和 PROCESSLIST，而不是第一反应去调池子大小。
