迁移后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 覆盖。
- 立刻执行：
mysqld --help --verbose | grep "Default options"，看实际加载路径列表 - 逐个检查这些路径下的文件，在
[mysqld]段内确认max_connections是否只定义一次、未被注释、没拼错段名 - 特别注意：写在
[client]或全局段下完全不生效；云数据库（如阿里云 RDS）根本不读本地配置文件，只能走控制台或 API
别只盯 max_connections，先看 wait_timeout 是否被重置
旧环境可能已把 wait_timeout 设为 300 秒，应用靠连接池复用；迁移后回退到默认 28800 秒，大量 Sleep 连接长期挂起，SHOW PROCESSLIST 里 Time 值超万秒，几分钟就占满连接数。
- 执行：
SHOW VARIABLES LIKE 'wait_timeout';，若返回28800，说明已被重置 - 临时修复：
SET GLOBAL wait_timeout = 300;（需 SUPER 权限） - 永久修复：在
[mysqld]段加wait_timeout = 300并重启；但注意 PHP 等短连接场景设太短会触发Lost connection to MySQL server
系统级文件描述符限制比 max_connections 还低
MySQL 启动时发现 ulimit -n 不够，会静默截断连接数——你配了 2000，实际生效可能只有 1024。
- 查当前限制：
ulimit -n；查 MySQL 进程实际上限：cat /proc/$(pidof mysqld)/limits | grep "Max open files" - 对 systemd 管理的服务，必须在
/usr/lib/systemd/system/mysqld.service的[Service]段加：LimitNOFILE=65536 - 改完必须执行：
systemctl --system daemon-reload && systemctl restart mysqld - 否则
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 值。
- 运行：
SHOW STATUS LIKE 'Max_used_connections';，对比当前max_connections—— 若长期 >95%，才说明真需要扩容 - 健康水位参考：
Max_used_connections / max_connections ≈ 70%~85% - 如果
Threads_connected很低却报错，大概率是max_user_connections限制或连接池配置冲突，不是上限问题
迁移后的连接雪崩，本质是旧配置失效 + 新环境限制暴露 + 应用行为未适配三者叠加。最容易被忽略的是：wait_timeout 和 ulimit 这两个“隐形开关”，它们不动，光调 max_connections 就像给漏水的桶拼命加水。
