如何解决MySQL迁移后由于数据库连接数限制（max_connections）导致的雪崩效应？

迁移后Too many connections错误根源在于配置加载顺序错乱、wait_timeout重置为28800秒导致Sleep连接堆积、系统ulimit限制低于max_connections三者叠加，需依次验证配置路径、timeout值及文件描述符上限，而非直接调大max_connections。

迁移后 Too many connections 报错，不是单纯调大 max_connections 就能解决的——它往往是多个层叠限制同时暴露的结果，直接硬调可能让问题更隐蔽、更难排查。

查清 MySQL 实际加载了哪个配置文件

迁移常导致配置路径变更或引入新片段（比如 Ubuntu 22.04+ 把配置拆进 /etc/mysql/conf.d/），你改的 my.cnf 可能被后面某个 mysqld.cnf 覆盖。

1. 立刻执行：mysqld --help --verbose | grep "Default options"，看实际加载路径列表
2. 逐个检查这些路径下的文件，在 [mysqld] 段内确认 max_connections 是否只定义一次、未被注释、没拼错段名
3. 特别注意：写在 [client] 或全局段下完全不生效；云数据库（如阿里云 RDS）根本不读本地配置文件，只能走控制台或 API

别只盯 max_connections，先看 wait_timeout 是否被重置

旧环境可能已把 wait_timeout 设为 300 秒，应用靠连接池复用；迁移后回退到默认 28800 秒，大量 Sleep 连接长期挂起，SHOW PROCESSLIST 里 Time 值超万秒，几分钟就占满连接数。

1. 执行：SHOW VARIABLES LIKE 'wait_timeout';，若返回 28800，说明已被重置
2. 临时修复：SET GLOBAL wait_timeout = 300;（需 SUPER 权限）
3. 永久修复：在 [mysqld] 段加 wait_timeout = 300 并重启；但注意 PHP 等短连接场景设太短会触发 Lost connection to MySQL server

系统级文件描述符限制比 max_connections 还低

MySQL 启动时发现 ulimit -n 不够，会静默截断连接数——你配了 2000，实际生效可能只有 1024。

1. 查当前限制：ulimit -n；查 MySQL 进程实际上限：cat /proc/$(pidof mysqld)/limits | grep "Max open files"
2. 对 systemd 管理的服务，必须在 /usr/lib/systemd/system/mysqld.service 的 [Service] 段加：LimitNOFILE=65536
3. 改完必须执行：systemctl --system daemon-reload && systemctl restart mysqld
4. 否则 SET GLOBAL max_connections = 1000 也会失败，错误日志里会有类似 Could not increase number of max_open_files to more than 1024

max_connections 设多大才算合理？

盲目设高反而危险：每个连接至少占 256KB 内存，1000 连接 ≈ 256MB 额外开销；且真正关键的是 Max_used_connections 值。

1. 运行：SHOW STATUS LIKE 'Max_used_connections';，对比当前 max_connections —— 若长期 >95%，才说明真需要扩容
2. 健康水位参考：Max_used_connections / max_connections ≈ 70%~85%
3. 如果 Threads_connected 很低却报错，大概率是 max_user_connections 限制或连接池配置冲突，不是上限问题

迁移后的连接雪崩，本质是旧配置失效 + 新环境限制暴露 + 应用行为未适配三者叠加。最容易被忽略的是：wait_timeout 和 ulimit 这两个“隐形开关”，它们不动，光调 max_connections 就像给漏水的桶拼命加水。