max_connections不生效主因是配置未正确加载或系统资源限制；需确认配置路径、[mysqld]段位置、文件权限，重启服务，并检查ulimit、云参数组及performance_schema定位连接源头。
max_connections 设置后不生效？检查配置加载路径和权限
MySQL 的 max_connections 是动态变量，但修改后不生效，大概率不是语法写错，而是配置没被正确加载。常见情况是改了 /etc/my.cnf 却用了 mysqld --defaults-file=/etc/mysql/my.cnf 启动，或者配置文件被多个位置的同名文件覆盖（比如 /etc/mysql/mysql.conf.d/mysqld.cnf 优先级更高）。
实操建议：
- 用
mysql -e "SHOW VARIABLES LIKE 'config_file';"确认 MySQL 实际读取的主配置文件 - 检查配置是否在正确的 section 下——必须写在
[mysqld]段内，写在[client]或全局段无效 - 确认启动用户有读取该配置文件的权限，尤其是 Docker 或 systemd 环境下，
mysqld进程可能以mysql用户运行，对/root/my.cnf不可读 - 修改后务必重启服务：
systemctl restart mysql（Debian/Ubuntu）或systemctl restart mysqld（RHEL/CentOS），仅SET GLOBAL是临时的，服务重启即丢失
SET GLOBAL max_connections 看似成功，但连接仍被拒绝？查 ulimit 和系统资源限制
即使 max_connections 设为 10000，MySQL 仍可能报 Too many connections，真实瓶颈常在操作系统层：每个 MySQL 连接对应一个线程，而线程数受 ulimit -u（最大用户进程数）和 /proc/sys/kernel/threads-max 限制。
实操建议：
- 登录 MySQL 后执行
SHOW VARIABLES LIKE 'max_connections';和SHOW STATUS LIKE 'Threads_connected';，确认当前值与实际使用量 - 在 shell 中运行
ulimit -u查看当前用户最大进程数，若低于max_connections + 后台线程数（如复制线程、InnoDB purge 线程等），需调高：sudo systemctl edit mysqld→ 添加LimitNPROC=65535 - 检查
dmesg | grep -i "out of memory"或journalctl -u mysqld | grep -i "cannot allocate memory"，内存不足时内核会直接 kill 线程，表现为“连接突然断开”而非明确报错
云数据库（RDS/Aurora）无法修改 max_connections？用参数组+重启策略绕过
阿里云 RDS、AWS Aurora 等托管服务禁止直接改配置文件，SET GLOBAL 也受限（部分版本只允许在参数组中调整）。这时候改错地方等于白改。
实操建议：
- 确认实例类型支持的连接数上限——例如 AWS t3.medium Aurora 最高只支持 2000 连接，设成 5000 也没用，先查文档或控制台规格表
- 在控制台找到「参数组」→ 编辑自定义参数组 → 修改
max_connections→ 关联到目标实例 → **触发重启**（注意：部分云厂商要求“重启后生效”，不是热加载） - 避免复用默认参数组，因为默认组通常被多个实例共享，误改会影响其他业务
- 修改前用
SELECT @@max_connections;记录原始值，便于回滚
连接数突增却找不到源头？用 performance_schema 定位异常客户端
调大 max_connections 只是缓解症状，真正要解决的是“谁在疯狂建连”。很多应用未复用连接池、短连接未及时 close、监控脚本高频探测，都会快速耗尽连接。
实操建议：
- 启用
performance_schema（5.7+ 默认开启），执行：SELECT host, user, COUNT(*) FROM performance_schema.threads JOIN information_schema.processlist USING(thread_id) GROUP BY host, user ORDER BY COUNT(*) DESC LIMIT 5; - 重点关注
host列：如果大量连接来自同一 IP 的不同端口（如10.0.1.2:54321,10.0.1.2:54322），基本是应用没配连接池或连接泄漏 - 配合
SHOW PROCESSLIST;观察Command列是否长期卡在Sleep，且Time值持续增长，说明连接空闲未释放 - 别只盯着
max_connections，也要检查应用侧的连接池配置（如 HikariCP 的maximumPoolSize、Druid 的maxActive），它应 ≤ MySQL 的max_connections× 0.8，留出管理连接余量
真正卡住人的从来不是怎么改配置，而是改完发现还是连不上——这时候八成是 ulimit 没调、云参数组没生效、或者根本没重启 mysqld。别急着加机器，先看 threads-connected 和 ulimit -u 的差值。还有，别信“设成 999999 就万事大吉”，连接数上去了，内存和文件描述符不一定跟得上。
