90%的“too many connections”源于连接未释放、超时设置过长或系统文件描述符限制，而非max_connections值过小；应先用root本地登录执行show variables like 'max_connections'、show status like 'threads_connected'和show status like 'threads_running'确认是否真满，若前者接近上限而后者极低，说明大量连接卡在sleep状态，多因应用未关闭连接或连接池与wait_timeout错配。
别急着改 max_connections——90% 的 “Too many connections” 不是连接数不够，而是连接没释放、超时设太长、或系统级文件描述符卡死了。先查清楚是不是真瓶颈，再动手。
怎么看当前连接压力是不是真高
连不上时，用 root 本地登录执行三句命令，比看报错更有价值：
-
SHOW VARIABLES LIKE 'max_connections';—— 看上限（新实例常是 151） -
SHOW STATUS LIKE 'Threads_connected';—— 当前挂着多少连接（含 Sleep） -
SHOW STATUS LIKE 'Threads_running';—— 此刻真正在干活的线程数
如果 Threads_connected 接近上限，但 Threads_running 只有 1～3，说明全是空闲连接堆着不放；SHOW PROCESSLIST; 里大量状态为 Sleep、Time 列持续增长，基本就是 wait_timeout 太大 + 应用没配好连接池。
怎么算一个安全又够用的 max_connections 值
不是拍脑袋定 1000 或 2000，而是结合两个真实数据取较大值后向上取整到 50 的倍数：
- 查历史峰值：
SHOW STATUS LIKE 'Max_used_connections';—— 自上次启动以来最高用过多少 - 算应用侧理论峰值：比如 4 台应用服务器 × HikariCP 的
maximumPoolSize = 50= 200，再加 30% 余量 ≈ 260 - 两者取大，比如 280 → 向上取整到 300；若长期稳定在 80 以下，151 就够用，别硬调
注意：这个值必须 ≤ 系统 ulimit -n 减去 200（留出日志、表缓存等开销），否则 MySQL 启动时会自动截断，或者运行中突然崩溃。
为什么 SET GLOBAL max_connections 经常“看似生效实则无效”
这条命令能立刻改，但有三道硬门槛常被跳过：
- 执行前先跑
ulimit -n：若返回 1024，而你想设 3000，MySQL 内部会默默按 1024 走，SET GLOBAL改不动 - systemd 服务默认限制更严：要编辑
/usr/lib/systemd/system/mysqld.service，在[Service]下加LimitNOFILE=65536，再systemctl --system daemon-reload && systemctl restart mysqld - 它只在当前进程生命周期内有效：MySQL 一重启就回退到配置文件值；生产环境必须写进
my.cnf的[mysqld]段，再重启
验证是否真生效：重启后执行 SELECT @@global.max_connections;，别只信配置文件内容；再查 cat /proc/$(pidof mysqld)/limits | grep "Max open files"，确保第一列 ≥ 你设的值 + 50。
比调参更关键的是用户级连接限制和 wait_timeout 匹配
全局 max_connections 调高了，但账号本身有更严上限，照样连不上：
- 给应用账号加限制：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 50;—— 立即生效，不用重启，且隔离风险 - 必须同步调低
wait_timeout（普通连接）到 300～600 秒；interactive_timeout（如 mysql 命令行）可保持 28800 - 应用连接池的
idleTimeout（如 HikariCP）必须 ≤ MySQL 的wait_timeout，否则池内连接会被 MySQL 主动 kill，日志出现Lost connection to MySQL server during query
真正卡住系统的，往往不是参数没设对，而是 wait_timeout 和连接池 idle 配置错位，导致连接反复创建销毁，或者长期滞留不释放——这种问题调再高的 max_connections 都只是延缓爆炸时间。
