MySQL 8日志中出现“Too many connections”错误如何排查与优化？

Question

MySQL 8 日志中频繁出现 “Too many connections” 错误，表明客户端连接数已超出 `max_connections` 限制（默认151）。该问题常导致新连接被拒绝、应用报错或服务不可用。排查需先确认当前连接数（`SHOW STATUS LIKE 'Threads_connected';`）、活跃连接及来源（`SELECT * FROM performance_schema.threads WHERE TYPE='FOREGROUND';` 或 `SHOW PROCESSLIST;`），重点关注长时间空闲、未释放的连接（如连接池配置不当、应用未调用 `close()`）。同时检查是否存在连接泄漏、短连接风暴或监控/备份工具高频建连。优化手段包括：合理调高 `max_connections`（需结合内存评估，每连接约占用2MB+）；启用 `wait_timeout`/`interactive_timeout` 缩短空闲超时；使用连接池（如 HikariCP）复用连接；审计应用连接生命周期；必要时通过 ProxySQL 或读写分离分摊连接压力。切忌盲目调大参数而忽视根本原因。

Answer 1

```html

一、现象识别：从日志到问题定性

MySQL 8 错误日志中高频出现 ERROR 1040 (HY000): Too many connections，表明服务端已达到 max_connections 硬限制（默认151）。该错误非瞬时偶发，而是持续性拒绝新连接，直接导致应用层 SQLException、HTTP 503、微服务熔断等连锁故障。需立即区分是“突发流量冲击”还是“连接资源持续淤积”——前者表现为短时峰值后快速回落，后者则呈现 Threads_connected 持续高位甚至缓慢爬升。

二、实时诊断：三层连接状态透视

• 全局水位：SHOW STATUS LIKE 'Threads_connected'; —— 查看当前总连接数（含空闲）
• 活跃会话：SHOW PROCESSLIST; 或 SELECT THREAD_ID, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_DB, PROCESSLIST_COMMAND, PROCESSLIST_TIME, PROCESSLIST_STATE FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_ID IS NOT NULL ORDER BY PROCESSLIST_TIME DESC;
• 连接来源画像：结合 PROCESSLIST_HOST 和 PROCESSLIST_USER 统计 TOP 5 连接源，识别异常 IP（如监控脚本、未收敛的定时任务）、匿名用户或共享账号滥用。

三、根因分类：五大典型模式对照表

类型	特征	验证命令	高危信号
连接泄漏	连接数随请求量线性增长且不回落	SELECT * FROM performance_schema.events_statements_summary_by_thread_by_event_name WHERE COUNT_STAR > 1000 AND EVENT_NAME LIKE 'statement/sql/%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;	大量 Sleep 状态连接超 wait_timeout
短连接风暴	每秒新建连接 > 50，Threads_created 持续飙升	SHOW GLOBAL STATUS LIKE 'Threads_created'; 对比历史趋势	应用未启用连接池，或池配置 minimumIdle=0

四、深度分析：内存与参数的耦合约束

调大 max_connections 不是解药，而是风险放大器。MySQL 8 每连接基础内存开销 ≈ 2MB（含 net_buffer、sort_buffer、read_buffer 等），若设为 1000，则仅连接内存即占用 2GB+。需同步评估：

SELECT 
  @@max_connections AS max_conn,
  @@wait_timeout AS wait_sec,
  @@interactive_timeout AS interactive_sec,
  @@innodb_buffer_pool_size / 1024 / 1024 / 1024 AS bp_gb,
  ROUND((@@max_connections * 2.1) / 1024, 1) AS est_conn_mem_gb;

五、架构级优化路径

graph LR A[Too many connections] --> B{根因定位} B --> C[应用层泄漏] B --> D[基础设施层风暴] B --> E[数据库层配置失当] C --> F[代码审计：ensure close/try-with-resources] C --> G[HikariCP 配置强化：leakDetectionThreshold=60000] D --> H[ProxySQL 连接复用/限流] D --> I[读写分离：只读流量导至从库] E --> J[动态调优：wait_timeout=60, max_connections=300] E --> K[启用 thread_cache_size=16 缓解创建开销]

六、生产就绪检查清单

1. ✅ 应用所有 JDBC URL 含 useSSL=false&serverTimezone=UTC&cachePrepStmts=true
2. ✅ HikariCP 中 connection-timeout=30000、idle-timeout=600000、max-lifetime=1800000
3. ✅ MySQL 配置文件中 wait_timeout = 60、interactive_timeout = 60、thread_cache_size = 16
4. ✅ 使用 pt-kill --busy-time 60 --victim all --interval 10 自动清理长 Sleep 连接（临时应急）
5. ✅ 在 Prometheus + Grafana 中建立 mysql_global_status_threads_connected 告警（阈值 > 85% max_connections）

七、反模式警示：那些看似合理实则危险的操作

盲目执行 SET GLOBAL max_connections = 2000; 而未评估内存压力，将导致 InnoDB Buffer Pool 竞争加剧、Page Cleaner 延迟升高；将 wait_timeout 设为 0（永不过期）等于纵容连接淤积；依赖 KILL 手动清理而非自动化治理，无法应对分布式环境下的海量实例管理。

```