云迁移后连接数不足的根源是应用层并发与数据库层限制未对齐，需同步调整php-fpm的pm.max_children、java连接池maximumpoolsize及云实例规格，并排查半开连接与健康检查堆积问题。
云迁移后连接数不足，不是配置没改够，而是应用层并发和数据库层限制没对齐——max_connections调高了，但 PHP-FPM 的 pm.max_children 或 Java 应用的连接池 maximumPoolSize 仍按旧环境粗放设置，结果新实例刚上线就报 Too many connections（错误 1040）。
查清当前连接上限和真实占用
别直接改配置。先确认是不是真满了，还是只是错觉：
-
SHOW VARIABLES LIKE 'max_connections';看服务端硬限制 -
SHOW STATUS LIKE 'Threads_connected';看当前活跃连接数 -
SHOW PROCESSLIST;扫一眼有没有大量unauthenticated user或长时间Sleep状态——前者多是健康检查探针或客户端建连失败卡住，后者大概率是应用没 close 连接
云数据库的 max_connections 不是随便调高的
云厂商（如 AWS RDS、阿里云 PolarDB、腾讯云 TDSQL-C）对 max_connections 有隐式约束：它和实例规格强绑定，比如 db.t3.small 默认只给 100，你硬在参数组里设成 1000，保存会成功，但实际生效值仍是 100。
- 查文档确认你所选规格对应的最大允许值，别信参数组里的“已修改”状态
- 升级实例规格比单纯调参更可靠；如果只是临时扛峰值，可配合连接池限流（如 HikariCP 的
connection-timeout和leak-detection-threshold） - MySQL 9.6.0 起引入
container_aware启动选项，云环境建议启用，它能自动适配容器资源限制，避免连接数超配
应用层并发必须压到连接池之下
云迁移常把本地单机部署改成多节点集群，但很多人忘了同步收紧应用并发——每个 PHP-FPM worker、每个 Spring Boot 实例，都默认独占一个连接。10 个节点 × 每节点 50 个进程 = 500 连接，远超云实例默认的 200。
- PHP-FPM：把
pm.max_children设为min(50, max_connections × 0.7)，留出余量给后台任务和监控 - Java（HikariCP）：
maximumPoolSize别超过max_connections × 0.8，同时开connection-test-query=SELECT 1防失效连接入库 - Node.js（mysql2）：显式控制
pool.max，别依赖默认值；CLI 脚本务必用pool.end()主动释放
别忽略云平台特有的半开连接堆积
云环境里最隐蔽的连接数杀手，是监控探针、健康检查、LB 健康探测这些“合法流量”。它们短频快、不认证、不发 SQL，只建 TCP 连接然后断开，但在网络抖动或超时设置过短时，会在 MySQL 的 SHOW PROCESSLIST 里卡成一堆 Connect + Receiving from client 状态。
- Google Cloud Monitoring、阿里云 ARMS 默认每 15 秒探一次，若 MySQL 的
connect_timeout是 2 秒，就容易堆积 - 解决方法：调大
connect_timeout（建议 ≥10），同时在 LB 层把健康检查间隔拉长到 30 秒以上 - 确认
skip-networking是 OFF，且mysqlx-bind-address和bind-address一致——云数据库导出的配置常带这两个坑
真正卡住的从来不是数字本身，而是应用进程数、连接池大小、云实例规格这三者的乘积。调任何一个，都得同步看另外两个的实际值，否则只是把压力从一处转移到另一处。
