迁移前必须评估源库负载、优化mysqldump配置、导入前禁用约束检查；迁移后需验证查询执行计划、innodb状态及缓冲池命中率，并确保字符集与排序规则一致。
迁移前必须做好的三件事
不评估源库负载就开干，迁移过程卡死、主从延迟暴涨是大概率事件。重点不是“怎么快”，而是“别让业务感知到慢”。
-
SHOW PROCESSLIST和pt-query-digest抓取迁移窗口期前 1 小时的慢查询与高频语句，确认SELECT是否大量依赖未命中索引的ORDER BY或LIMIT - 检查源库
innodb_buffer_pool_size是否已接近物理内存 70%，若迁移期间并发读写激增，buffer pool 不足会直接触发大量磁盘 IO - 确认目标库 MySQL 版本是否启用
innodb_dedicated_server（8.0.13+），该开关会自动调优 buffer pool、log file size 等参数，手动设错反而拖累性能
mysqldump 导出时性能掉坑的典型配置
mysqldump 默认单线程、全表锁（--lock-tables）、禁用扩展插入（--skip-extended-insert），导出 10GB 以上表时极易拖垮源库。
- 必加参数：
--single-transaction --skip-lock-tables --extended-insert --routines --triggers --set-gtid-purged=OFF - 大表务必分片导出：用
WHERE条件按主键范围切分（如id BETWEEN 1 AND 1000000），避免单次事务过大导致 undo log 膨胀或锁等待 - 避免
--opt（默认开启），它隐含--add-drop-table和--disable-keys，在目标库导入时重建索引反而更慢；改用--skip-disable-keys让索引随数据逐步构建
目标库导入阶段最关键的两个动作
导入不是“把 SQL 执行完就行”，MySQL 的恢复机制对写入模式极度敏感。
- 导入前执行：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; SET AUTOCOMMIT=0;，导入完成后再恢复，否则每行都校验外键和唯一约束，速度可能下降 5–10 倍 - 使用
mysql --max-allowed-packet=512M -u user db_name ，<code>max_allowed_packet必须大于最大单条 INSERT（尤其是含大字段或批量插入场景），否则报错Packets larger than max_allowed_packet are not allowed并中断导入
迁移后必须验证的三个性能基线
迁移完成不等于稳定，很多性能问题在第二天高峰才暴露。
- 对比迁移前后相同查询的
EXPLAIN FORMAT=JSON输出，重点关注used_columns、rows_examined_per_scan是否突增，尤其注意 JSON 字段路径表达式是否因版本差异失效 - 检查
SHOW ENGINE INNODB STATUS\G中SEMAPHORES和TRANSACTIONS部分，若spin_waits或rw_lock_spins明显升高，说明 buffer pool 或 log system 成为瓶颈 - 观察
information_schema.INNODB_METRICS表中innodb_buffer_pool_read_requests与innodb_buffer_pool_reads的比率，低于 99% 就说明缓存命中严重不足，得调大innodb_buffer_pool_size
实际中最容易被忽略的是字符集和排序规则迁移一致性——源库用 utf8mb4_0900_as_cs，目标库若误配成 utf8mb4_general_ci，会导致索引无法下推、隐式转换，查询计划彻底失真。
