先查max_connections与Threads_connected是否真正接近，再排查max_user_connections、云平台配额、连接泄漏或慢查询；临时调参需兼顾内存与系统文件描述符限制，永久修改须同步更新my.cnf和systemd配置。
直接调高 max_connections 只能缓解表象，不查清连接堆积原因，改完很快又满——尤其当 Threads_connected 接近甚至超过 max_connections 时，说明已有大量连接滞留未释放。
怎么确认是不是真到了上限？
别只看报错就急着改配置。先登录 MySQL 执行：
SHOW VARIABLES LIKE 'max_connections';<br>SHOW STATUS LIKE 'Threads_connected';<br>SHOW STATUS LIKE 'Max_used_connections';
如果 Threads_connected 比如是 298，而 max_connections 是 300，那确实是硬性卡死；但如果 Threads_connected 只有 40，却报错，大概率是用户级限制或连接池配置冲突。
-
max_user_connections对单个账号做了限制（默认 0 表示不限），可用SELECT user, host, max_connections FROM mysql.user;查 - 某些云数据库（如腾讯云 CDB）会额外限制“活跃会话数”，和
max_connections无关，得去控制台看配额 -
show full processlist里大量状态为Sleep或Cleaning up，说明应用没正确关闭连接，不是上限问题，是泄露
临时调参：set global max_connections 生效但有风险
运行中执行 SET GLOBAL max_connections = 500; 立即生效，不用重启。但要注意：
- 该操作不持久，MySQL 重启后恢复原值
- 内存占用会上升：每个连接约消耗 256KB～1MB 内存（取决于 buffer、sort 等设置），盲目设到 2000+ 可能触发 OOM
- 若系统级文件描述符不足（
ulimit -n太小），即使设了 1000，MySQL 实际也只起效到 214（常见于 MariaDB/CentOS7） - Percona/MariaDB 支持
SET PERSIST max_connections = 500;，可写入 mysqld-auto.cnf 持久化，MySQL 8.0.22+ 也支持
永久修改必须配 my.cnf + 检查系统限制
在 [mysqld] 段下加：
[mysqld]<br>max_connections = 500<br>wait_timeout = 300<br>interactive_timeout = 300
但改完重启失败或值没生效，八成是被系统级限制拦住了：
- Linux 默认
ulimit -n是 1024，MySQL 启动时若要求打开 500+ 连接，需先确保系统允许：检查/usr/lib/systemd/system/mysqld.service或mariadb.service，在[Service]下加LimitNOFILE=65536 - systemd 配置改完要执行
systemctl daemon-reload && systemctl restart mysqld - 注意
wait_timeout和应用连接池的max-wait、idle-timeout匹配，否则连接池可能拿回一个已被 MySQL 主动断开的连接，抛Connection reset或空指针
真正压垮连接数的往往不是并发量，而是慢查询和连接泄漏
见过太多案例：业务 QPS 才 20，Threads_connected 却飙到 400+。根本原因常是：
- 应用代码里
Connection/Statement/ResultSet没在finally块或 try-with-resources 中关闭 - 用了 Druid/HikariCP 却把
max-active设成 200，而min-idle设成 0，高峰期创建一堆连接后，空闲连接不回收 - 某条 SQL 全表扫描 +
ORDER BY RAND()，单次执行 8 秒，连接卡在Sending data状态，积压后连锁阻塞 - 监控发现
Max_used_connections长期在 30 左右，但某天突然跳到 480，立刻查slow_log和processlist，十有八九定位到异常任务
连接数问题从来不是孤立参数问题——max_connections 是水位线，而 wait_timeout、应用连接池策略、SQL 效率、系统资源，才是决定水位高低的真正阀门。
