mysql迁移过程中如何保证性能不下降_mysql性能调优建议

迁移前必须评估源库负载、优化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 STATUSG 中 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，会导致索引无法下推、隐式转换，查询计划彻底失真。