直接调高max_connections仅缓解表象，真正有效的是“限流+释放+优化”三管齐下：先用show status和show variables确认是否真达上限，再查sleep连接、慢查询及连接泄漏，结合内存合理调参，并实施前端限流、连接池收紧与空闲连接主动清理。
直接调高 max_connections 并不能彻底解决突发流量导致的连接数爆满问题，它只是缓解表象；真正有效的做法是“限流 + 释放 + 优化”三管齐下。
先确认是不是真到了连接数上限
别一看到“Too many connections”就急着改配置。先登录 MySQL 执行：
SHOW STATUS LIKE 'Threads_connected';<br>SHOW VARIABLES LIKE 'max_connections';
如果 Threads_connected 接近甚至等于 max_connections，才说明确实被占满了。但更要查：
-
有没有长连不释放？比如应用没调用
close()，或连接池配置不合理（最小空闲数过高、空闲超时过长） -
有没有慢查询堆积？执行
SHOW PROCESSLIST;看是否有大量State为Sending data、Locked或Copying to tmp table的线程 -
是不是连接泄漏？观察
Threads_created是否持续飙升（说明频繁新建连接，旧连接没复用）
合理调整 max_connections 的关键细节
盲目设成 10000 不但无效，还可能因内存耗尽触发 OOM。MySQL 每个连接默认占用约 2–3MB 内存（受 sort_buffer_size、read_buffer_size 等影响），实际可支撑的连接数 ≈ 可用内存 ÷ 单连接内存开销。
- 线上建议：从当前值开始，每次只增加 20%～50%，比如原为 200，先试 300，并配合监控观察内存和响应延迟
- 修改方式分两步：
① 临时生效（重启失效）：SET GLOBAL max_connections = 300;
② 永久生效：在my.cnf的[mysqld]段添加max_connections = 300，然后重启 - 注意：有些云数据库（如阿里云 RDS、腾讯云 CDB）不支持直接改该参数，需在控制台调整“连接数规格”并重启实例
比调参更关键的三项实战措施
连接数爆满本质是资源错配，不是容量不够。
- 前端加限流：Nginx 或 API 网关层按 IP/用户/接口维度限制并发连接数或 QPS，把洪峰削平
-
应用层连接池收紧：例如 HikariCP 设置
maximumPoolSize=20、idleTimeout=30000、connectionTimeout=3000，避免创建过多空闲连接 -
主动 kill 无用连接：对运行超 60 秒的空闲连接（
Command=Sleep且Time > 60），可用脚本定期清理：SELECT CONCAT('KILL ',id,';') FROM information_schema.processlist WHERE Command = 'Sleep' AND Time > 60;
长期必须做的根治动作
连接数告警往往是系统性问题的最后表现。
- 给所有查询加上
MAX_EXECUTION_TIME(3000)（MySQL 5.7.8+），防止单条 SQL 卡死连接 - 检查慢查询日志，对全表扫描、缺失索引、大字段
SELECT *的 SQL 做针对性优化 - 读写分离：将报表、后台导出等低优先级查询路由到从库，减轻主库连接压力
- 考虑连接复用方案，比如 ProxySQL 或 MySQL Router，统一管理连接生命周期
