还原后连接数剧增主因是表损坏、索引失效或统计信息陈旧引发慢查询与锁等待；须立即执行analyze table（innodb）或repair table（myisam），并同步调整应用连接池idle-timeout参数。
还原后连接数剧增，基本不是还原操作本身导致的，而是还原触发了某些被掩盖的问题——比如表损坏、索引失效、统计信息陈旧，进而引发慢查询或锁等待，让连接卡在 Sleep 或 Locked 状态不释放。
为什么还原后突然连接数飙升？
数据库还原（尤其是从旧备份恢复）常伴随以下隐性风险：
- MyISAM 表可能损坏，
CHECK TABLE显示status: crash，查询会 hang 住连接 - InnoDB 统计信息未更新，优化器生成错误执行计划，全表扫描拖长事务时间
- 还原后未执行
ANALYZE TABLE，导致 join 或 where 条件走错索引，查询变慢 - 备份时存在长事务未提交，还原后这些事务状态残留，
information_schema.INNODB_TRX中仍可见 - 还原覆盖了
wait_timeout配置，但应用连接池未同步调整，空闲连接超时时间错配
先确认是不是真“剧增”，还是假象
别急着 kill 连接，先跑这三条命令看本质：
SHOW GLOBAL STATUS LIKE 'Threads_connected'; —— 当前总连接数
SHOW GLOBAL STATUS LIKE 'Threads_running'; —— 正在干活的连接数（非 Sleep）
SHOW VARIABLES LIKE 'max_connections'; —— 看是否真逼近上限
如果 Threads_connected 是 200，Threads_running 只有 3，说明 197 个是空闲连接——问题不在负载高，而在连接没释放或释放太慢。
重点查还原后最易出问题的三类连接
执行 SHOW FULL PROCESSLIST;，重点关注：
-
Time > 60 且 Command = Sleep：大概率是应用没关连接，或
wait_timeout设置过大（如 28800 秒），而连接池 idle 超时设得更短，造成“连接池想回收、MySQL 不放人” -
State = Sending data / Sorting result / Locked：对应 SQL 正在执行但卡住了，立刻查
info列里的语句，用EXPLAIN看是否走了索引 - User = 'xxx'@'10.x.x.x' 且 Host 异常集中：可能是某台应用服务器配置错，反复重连或未启用连接池
特别注意还原后首次执行的报表类 SQL 或定时任务——它们往往没压测过，一跑就占连接几十秒。
还原后必须立即做的四件事
这不是可选项，是止损动作：
- 对所有被还原的业务表执行
ANALYZE TABLE `table_name`;（InnoDB）或REPAIR TABLE `table_name`;（MyISAM） - 检查并同步连接池参数：
spring.datasource.hikari.idle-timeout必须 wait_timeout，建议设为30000（30 秒） - 临时启用慢日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;，跑 10 分钟抓出首屏慢 SQL - 查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE trx_started ，手动 <code>KILL掉异常事务 ID
还原不是终点，而是新问题暴露的起点。很多团队只关注“数据回来了”，却忽略统计信息、锁状态、连接生命周期这些隐形依赖——等连接数涨到 500+ 才发现，其实第一笔查询就该加 ANALYZE。
