SET GLOBAL max_connections不生效主因是系统级文件描述符限制（ulimit -n）低于设定值，MySQL启动时自动向下取整；需检查配置加载路径、确认[mysqld]段位置、调整LimitNOFILE/LimitNPROC并重启服务。
直接调大 max_connections 只能缓解表象，不解决连接堆积的根本原因；盲目设高反而可能触发系统级限制或内存耗尽。
为什么 SET GLOBAL max_connections 有时不生效
常见现象是执行 SET GLOBAL max_connections=1000 后查 SHOW VARIABLES LIKE 'max_connections' 还是旧值。根本原因通常是操作系统级文件描述符限制（ulimit -n）低于新设定值，MySQL 启动时会自动向下取整到可支持的最大值。
验证方式：
- 运行
ulimit -n查看当前限制（如返回 1024，而你想设max_connections=2000，必然失败） - 检查 MySQL 错误日志，常含类似
Could not increase number of max_open_files to more than 1024 (request: 2000) - 对 systemd 管理的 MySQL/MariaDB，需在
/usr/lib/systemd/system/mysqld.service或mariadb.service的[Service]段添加：LimitNOFILE=65536LimitNPROC=65536 - 修改后必须执行：
systemctl --system daemon-reload && systemctl restart mysqld
my.cnf 里配了 max_connections 却没生效
不是所有配置文件都会被读取，MySQL 启动时只加载一个主配置文件（可通过 mysqld --help --verbose | grep "Default options" 确认路径），且 [mysqld] 段外的 max_connections 会被忽略。
关键检查点：
- 确认配置写在正确的段落：
[mysqld]，不是[client]或全局段 - 避免重复定义：多个配置文件中都写了
max_connections，以最后加载的为准 - MySQL 8.0.22+ 支持
SET PERSIST max_connections = 1000，该命令会持久化到mysqld-auto.cnf，优先级高于 my.cnf —— 若已用此方式设置，改 my.cnf 也不覆盖 - 重启后务必验证：
SELECT @@global.max_connections;，别只信配置文件内容
max_connections 设多大才算合理
没有固定值，取决于内存、并发模型和连接存活时间。设太高反而危险：
- 每个连接至少占用 256KB 内存（受
sort_buffer_size、read_buffer_size等影响），1000 连接 ≈ 256MB 额外开销 - 真正有意义的是
Max_used_connections值：运行SHOW STATUS LIKE 'Max_used_connections';，若长期接近max_connections，说明要么业务突增，要么有连接泄漏 - 健康水位参考：
Max_used_connections / max_connections ≈ 70%~85%；持续 >95% 就该查SHOW PROCESSLIST里大量Sleep状态连接的来源 - 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁止修改
max_connections，应优先优化应用侧连接池和超时设置
比调参数更关键的三件事
绝大多数 Too many connections 报错，根源不在 MySQL 本身，而在应用层未释放连接或连接池失控：
- 检查连接池最大活跃数（如 Druid 的
max-active、HikariCP 的maximumPoolSize）是否远超max_connections，例如 DB 允许 300 连接，但 10 个服务各配了 100 连接池，瞬间就打满 - 确认
wait_timeout和interactive_timeout是否设得过大（如 28800 秒 = 8 小时），导致空闲连接长期不释放；生产建议设为 300～600 秒 - 代码里有没有漏掉
connection.close()？尤其在异常分支、异步回调、Filter/Interceptor 中——这类泄漏不会报错，但连接数会缓慢爬升直至崩盘
临时救急可以 kill 掉长时间 Sleep 连接（KILL <code>id），但只要泄漏点还在，几小时后又会复现。真正要盯住的，永远是 SHOW PROCESSLIST 里那些活过 5 分钟却没干活的连接从哪来。
