真正要清理的是Sleep且Time超300秒或指向已下线旧IP/域名的连接；需先过滤旧客户端、核对连接池配置，再用条件SQL生成KILL语句人工审核执行，并同步调整wait_timeout和interactive_timeout至300-600秒，最后清理残留配置文件。
确认哪些连接真该被清理
迁移后出现“连接数飙升”“应用报 Too many connections”，往往不是连接本身有问题，而是旧配置残留导致新实例误判空闲连接、或客户端反复重连失败堆积。真正要清理的，是那些状态为 Sleep 且 Time 超过业务合理阈值（比如 300 秒）的连接，以及明确指向已下线旧IP/域名的连接（如 host: 10.0.1.5:54283，而新架构已切到内网VIP）。
不要一上来就 KILL 所有 Sleep 连接——有些是ORM连接池的保活心跳，杀掉反而触发重建风暴。
实操建议：
• 先执行 SHOW FULL PROCESSLIST;，导出结果用文本工具过滤 Host 列，快速识别旧客户端来源
• 对比迁移前后的 max_connections 和应用连接池配置（如 HikariCP 的 maximumPoolSize），确认是否因配置不匹配人为制造了长连接堆积
用 SQL 精准批量终止无效连接
手动 KILL 逐个ID效率低还易漏，但直接写脚本全杀又危险。更稳妥的是生成带条件的 KILL 语句，人工审核后再执行。
例如，清理所有来自已废弃子网、空闲超5分钟、且非系统用户的连接：SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE host LIKE '192.168.2.%' AND command = 'Sleep' AND time > 300 AND user NOT IN ('system_user', 'replication');
注意：
• information_schema.processlist 中的 time 是秒级，单位别搞错
• command = 'Sleep' 不等于“无用”，需结合 user 和 host 综合判断
• MySQL 8.0+ 支持 KILL CONNECTION（推荐），而老版本只认 KILL，语法兼容性要核对
改配置比删连接更治本：调整 wait_timeout 和 interactive_timeout
很多无效连接其实是“不该存在却一直挂着”，根源在服务端超时设置太宽松。迁移后若沿用旧配置（比如 wait_timeout = 28800，即8小时），会导致连接池未主动关闭的连接长期滞留。
必须同步调整两个参数：
• wait_timeout：控制非交互式连接（如 JDBC 普通连接）空闲超时
• interactive_timeout：控制交互式连接（如 mysql client）空闲超时
建议值：
• 生产环境设为 300（5分钟）或 600（10分钟），与应用连接池的 idleTimeout 对齐
• 修改方式：写入 my.cnf 的 [mysqld] 段，然后 systemctl restart mysqld（注意：动态 SET GLOBAL 在重启后失效）
• 验证是否生效：SELECT @@wait_timeout, @@interactive_timeout;
清理残留配置文件，避免下次启动加载错误参数
迁移常伴随多版本共存，比如旧版 MySQL 5.7 卸载不干净，其 /etc/my.cnf 或 /etc/mysql/conf.d/old-override.cnf 仍存在，新 MySQL 8.0 启动时可能意外加载这些含过时参数（如 query_cache_type）的文件，间接影响连接行为甚至报错。
检查并清理这些位置：
• /etc/my.cnf
• /etc/mysql/my.cnf
• /etc/mysql/conf.d/ 下所有 .cnf 文件
• /usr/etc/my.cnf（部分源码编译安装路径）
操作前务必：
• 用 mysqld --help --verbose | grep "Default options" 确认当前实际读取的配置文件路径
• 对疑似残留文件先 mv xxx.cnf xxx.cnf.bak 备份，再重启验证，别直接 rm
最容易被忽略的点是：清理连接只是表象，真正卡住人的往往是配置文件加载顺序和权限残留。尤其在 CentOS 和 Ubuntu 混合运维环境中，/etc/mysql/conf.d/ 下一个 5.7 时代的 timeout.cnf 就能让 8.0 实例悄悄继承错误的 wait_timeout，而日志里几乎不报错。
