MySQL迁移导致连接中断或查询变慢的直接原因是锁表、主从延迟、网络抖动、缓冲区重建等副作用引发的资源争抢和状态重置，而非迁移动作本身。
迁移过程中 MySQL 连接中断或查询变慢的直接原因
MySQL 数据库迁移本身不改变运行时性能，但迁移操作会引发锁表、主从延迟、网络抖动、缓冲区重建等副作用，导致应用侧感知为“性能下降”。关键不是迁移动作本身，而是它触发的资源争抢和状态重置。
-
mysqldump全量导出时若未加--single-transaction，对 InnoDB 表可能触发全局读锁（尤其在低版本或含 MyISAM 表时） - 主从切换期间，如果新主库的
innodb_buffer_pool_size未按目标机器内存重新配置，缓存命中率会骤降，SELECT延迟明显上升 - 迁移后首次执行复杂查询时，执行计划可能因统计信息过期而劣化——
ANALYZE TABLE不会自动触发，需手动补全
验证迁移后性能是否真实的三类必测场景
不能只看 QPS 或平均响应时间。真实性能回归要覆盖数据层行为变化，重点验证以下三类：
-
点查路径：用原业务中高频的
WHERE id = ?或带覆盖索引的SELECT，对比迁移前后EXPLAIN FORMAT=JSON中的key、rows_examined和used_columns是否一致 -
写入吞吐：模拟批量
INSERT ... VALUES (),(),...和单条INSERT INTO ... SELECT，观察innodb_log_waits和Threads_running是否突增——这反映日志刷盘或锁竞争是否恶化 -
长事务影响：在迁移后新库上开启一个未提交事务，再并发执行 DML，检查
INFORMATION_SCHEMA.INNODB_TRX中的trx_mysql_thread_id和trx_weight是否异常增长，避免隐藏的锁升级问题
容易被忽略的配置漂移项
迁移常只同步表结构与数据，却漏掉会显著影响性能的服务端参数。以下几项必须人工核对：
-
sort_buffer_size：默认值通常偏小（256KB），高并发ORDER BY场景下易退化为磁盘排序；迁移后应按实际并发数 × 单次排序量估算 -
join_buffer_size：若业务存在多表关联且未走索引，该值过小会导致嵌套循环次数暴增；注意它不支持动态修改，需重启生效 -
max_connections与wait_timeout的组合：迁移后连接池配置若未同步调整，可能触发大量Lost connection to MySQL server during query错误，表现为偶发超时而非持续慢 - 时区设置：
system_time_zone和time_zone不一致会导致NOW()、CONVERT_TZ()结果错位，间接影响基于时间分区的查询性能
用 pt-query-digest 快速定位迁移引入的性能拐点
比起人工比对慢日志，更可靠的方式是用 pt-query-digest 对比迁移前后的查询分布。核心不是看“哪条 SQL 变慢了”，而是看“哪类执行模式占比变了”：
- 执行时间分布右移（如 95% 分位从 10ms → 80ms）：大概率是缓存未预热或索引失效
-
Rows_examined中位数跳升但Rows_sent不变：说明过滤条件未走索引，或新增了隐式类型转换 - 出现大量
Using temporary; Using filesort标记：指向tmp_table_size或max_heap_table_size设置不合理，或ORDER BY字段缺失索引 - 同一
Query_ID在迁移后Lock_time显著升高：说明锁粒度或持有时间变化，需结合performance_schema.data_locks追踪
真正难排查的，往往是那些没报错、没告警、但整体 P99 毛刺变多的“软降级”——它们通常藏在配置漂移和统计信息失准里，而不是迁移工具本身。
