单纯调大max_connections只是止痛药，不解决根本问题；连接池能缓解但用错反而加重负担。原因包括操作系统文件描述符限制、systemd服务配置未同步、应用端连接未释放、连接池大小设置过大、连接泄漏未监控、读写流量未分离，以及慢查询引发的连锁反应。
直接说结论：单纯调大 max_connections 只是止痛药，不解决根本问题；连接池能缓解但用错反而加重负担。
为什么 set GLOBAL max_connections=2000 之后还是报错
常见现象是执行了 set GLOBAL max_connections=2000，立刻查 show variables like 'max_connections' 确实变了，但过几分钟又出现 Too many connections。原因往往不是参数没生效，而是：
- 操作系统级限制没同步改：MySQL 实际能打开的连接数受
ulimit -n（文件描述符上限）制约，比如系统只允许 1024 个 fd，MySQL 就算设成 2000 也最多用到 1024 - systemd 服务配置被忽略：在 CentOS 7+/Ubuntu 16.04+ 上用 systemd 启动 MySQL/MariaDB 时，
/etc/my.cnf里改了max_connections，但/usr/lib/systemd/system/mysqld.service里没配LimitNOFILE，重启后仍卡在默认值 - 应用端没释放连接：Java 应用用了
Connection却没调close()，PHP 用了mysql_connect()没mysql_close()，连接持续堆积，直到耗尽
连接池不是万能解药，用错会雪上加霜
很多人以为“上了 HikariCP 或 Druid 就万事大吉”，结果发现连接数不降反升。关键点在于：
- 池大小设得比
max_connections还大：比如数据库只允许 300 连接，却把 HikariCP 的maximumPoolSize设成 500，多个服务实例一启动就抢光资源 - 连接泄漏未监控：HikariCP 的
leakDetectionThreshold默认关闭，连接被借出后长期不归还，池不断新建连接填补空缺，最终打爆数据库 - 没区分读写流量：所有请求都打到主库，而主库连接数本就紧张；读多写少场景下，该走从库的查询硬塞进主库连接池
真正有效的三步排查顺序
别一上来就改配置或换组件。先定位瓶颈在哪一层：
- 看
SHOW PROCESSLIST输出里大量连接处于什么状态：Sleep多？说明应用没关连接；Cleaning up或Query卡住？说明 SQL 执行慢或锁表；Waiting for table metadata lock？大概率有长事务或未提交 DDL - 对比
SHOW STATUS LIKE 'Threads_connected'和SHOW STATUS LIKE 'Max_used_connections'：如果前者远小于后者，说明峰值已过但连接没回收，重点查应用层；如果两者接近且持续高位，说明当前负载真实压满 - 查
SHOW ENGINE INNODB STATUS\G里的TRANSACTIONS和SEMAPHORES部分：有没有事务持有锁超 60 秒？有没有os_waits高企？这些才是连接堆积的根因
最常被忽略的一点：很多“连接数过多”实际是慢查询拖垮的连锁反应——一条全表扫描的 UNION 查询卡住 10 秒，100 个并发进来就堆出 100 个 Query 状态连接，此时调大 max_connections 只会让数据库更卡，而不是更快。
