迁移后连接数飙升主因是旧配置在新环境失效，如wait_timeout与连接池idleTimeout不匹配、持久连接未关闭、账号限流缺失等，需重点校准参数、启用有效性检测并精准定位泄漏源。
迁移后连接数突增不是数据库“变坏了”，而是旧环境里被掩盖的连接管理缺陷，在新实例上集中暴露了。直接调大 max_connections 会加速内存耗尽，必须从配置校准、连接有效性、泄漏定位三方面同步处理。
为什么迁移后连接数会突然飙升
旧库可能长期运行在宽松配置下（比如 wait_timeout = 28800），应用连接池却没配 idleTimeout，靠数据库被动断连“凑合活着”；迁到新库后，若未同步调整，就会出现大量“看似活着、实则已断”的连接堆积在池中。复用时抛 Connection reset 或卡在 Sleep 状态，应用不断新建连接补位，形成雪崩。
- PHP 用户重点查
mysql.allow_persistent = On或遗留的mysql_pconnect() - Node.js 检查
mysql2初始化是否传了enableKeepAlive: true但没设keepAliveInitialDelay - Java 应用确认 HikariCP/Druid 是否启用了
connection-test-query=SELECT 1，否则池子里全是僵尸连接
必须立刻校准的三个关键参数
迁移后不能复用旧连接池配置。新实例的 wait_timeout、内存、负载能力都不同，旧参数极易引发泄漏或雪崩。
-
idleTimeout必须比 MySQL 的wait_timeout小至少 30 秒：例如新库wait_timeout = 300，HikariCP 就得设idle-timeout=270000 -
maximumPoolSize不能照搬旧值：按公式重算——应用实例数 × 每实例平均并发连接数 × 1.2，再向上取整 - 必须开启连接有效性检测：
connection-test-query=SELECT 1（HikariCP 5.0+）或validationQuery=SELECT 1（Druid）
如何快速识别并清理泄漏连接
别只看 SHOW PROCESSLIST，它截断 SQL 且不显示创建时间。要用 performance_schema.processlist 定位真问题：
- 执行
SELECT ID, USER, HOST, COMMAND, TIME, STATE, INFO FROM performance_schema.processlist WHERE COMMAND = 'Sleep' AND TIME > 600 ORDER BY TIME DESC; - 若
TIME值持续增长（比如从 60 秒涨到 1200 秒），基本可判定是连接泄漏 - 重点关注
HOST集中在某台应用服务器 IP，指向该服务连接池未关闭连接或未正确配置idleTimeout
临时止血时 KILL 连接的避坑要点
盲目 KILL 可能干掉主从复制线程或监控探针。先排除安全线程：
- 执行
SELECT ID, USER, HOST, COMMAND FROM information_schema.processlist WHERE COMMAND IN ('Binlog Dump', 'Connect', 'Daemon');——这些不要动 - 真正该清理的是：
USER是应用账号（如app_user）且COMMAND = 'Sleep'且TIME > 600 - 批量生成命令示例：
SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE USER = 'app_user' AND COMMAND = 'Sleep' AND TIME > 600;，复制结果手动执行，避免脚本误伤
最易被忽略的一点：账号级连接限制。迁移后常只调 max_connections，却忘了给每个业务账号单独限流，比如 ALTER USER 'app_user'@'%' WITH MAX_CONNECTIONS_PER_HOUR 3600;。这能防止单个服务异常拖垮整个实例。
