MySQL连接数飙升主因是旧配置在新环境失效，如wait_timeout与连接池idleTimeout不匹配、持久连接未关闭、账号限流缺失等，需重点校准参数、启用有效性检测并精准定位泄漏源。
连接数飙升不是迁移导致的，是旧配置在新环境里“失效”了
MySQL迁移后连接数暴涨，90%的情况不是迁移本身出问题，而是原环境里被掩盖的连接管理缺陷，在新实例上暴露了。比如老库 wait_timeout 设成 8 小时，应用连接池却没配 idleTimeout，靠数据库被动断连“凑合活着”；迁到新库后，如果新库 wait_timeout 恢复默认值（仍是 28800），而连接池仍按老逻辑运作，就会出现大量“看似活着、实则已断”的连接堆积在池中，下次复用直接报 Connection reset 或卡在 Sleep 状态。
查清是不是持久连接（persistent connection）在捣鬼
PHP、Node.js（mysql2）、某些 Python ORM 默认启用持久连接，它不走连接池逻辑，而是复用底层 socket。迁移后若未显式关闭，会导致连接长期不释放，尤其在 Apache prefork 模式或长生命周期进程里。
- 执行
SHOW PROCESSLIST;，看Command列是否大量为Sleep，且Time值从迁移后持续增长（如从 10 秒涨到 300+ 秒） - PHP 用户检查
php.ini是否含mysql.allow_persistent = On或代码里用了mysql_pconnect()（已废弃但仍有遗留） - Node.js 检查
mysql2初始化时是否传了enableKeepAlive: true且没配keepAliveInitialDelay - 确认 Web 服务器是否复用进程/线程——Nginx + PHP-FPM 的
pm.max_children和pm.start_servers会直接影响持久连接总数
HikariCP / Druid 连接池参数必须重校准
迁移后不能直接复用旧连接池配置。新 MySQL 实例的 wait_timeout、内存、负载能力都可能不同，旧参数极易引发泄漏或雪崩。
-
idleTimeout必须比 MySQL 的wait_timeout小至少 30 秒：例如新库设了wait_timeout = 300（5 分钟），HikariCP 就得设idle-timeout=270000；Druid 对应minEvictableIdleTimeMillis=270000 -
maximumPoolSize不能照搬旧值：需按公式重算——应用实例数 × 每实例平均并发连接数 × 1.2，再向上取整；避免多个服务共用库时叠加超限 - 必须开启连接有效性检测：
connection-test-query=SELECT 1（HikariCP 5.0+）或validationQuery=SELECT 1（Druid），否则池子里的“僵尸连接”会越积越多 - Java 应用加
leak-detection-threshold=60000（单位毫秒），能快速捕获未 close 的连接，日志里直接打出堆栈
别忽略账号级连接限制和应用名识别
迁移后常只调 max_connections，却忘了给每个业务账号单独限流。一个服务出 bug，不该拖垮整个库。
- 立刻执行：
ALTER USER 'app_payment'@'%' WITH MAX_USER_CONNECTIONS 80;（数值按实际压测结果定，别拍脑袋） - MySQL 5.7+ 支持通过
program_name区分客户端：应用启动时在 JDBC URL 加&program=order-service，再配合INFORMATION_SCHEMA.PROCESSLIST的PROGRAM_NAME字段精准定位异常来源 - 临时应急可查并清理真实空闲连接：
SELECT CONCAT('KILL ', ID, ';') FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 600 AND ID NOT IN (SELECT TRX_MYSQL_THREAD_ID FROM INFORMATION_SCHEMA.INNODB_TRX);，复制结果后执行，避免误杀事务中连接
最易被忽略的是：连接池的 idleTimeout 和 MySQL 的 wait_timeout 必须形成“时间差”，不是数值一致就行；差值太小会频繁回收，太大则泄漏。这个差值要写进部署 checklist，每次迁移都核对，而不是靠经验猜测。
