MySQL迁移监控需实时跟踪数据量、剩余时间、错误日志及关键指标：查Seconds_Behind_Master判断复制延迟；用COUNT(*)或TABLE_ROWS比对行数估算导入进度；监控iostat/iftop和SHOW PROCESSLIST观察资源与线程状态；借助myloader/XtraBackup等工具进度提示；并定期校验关键记录一致性。
MySQL迁移过程中监控进度，核心是实时掌握数据传输量、剩余时间、错误日志和关键指标变化。不能只依赖“还在运行”这种模糊反馈，得有可量化的依据。
查看主从复制延迟（适用于基于binlog的逻辑迁移）
如果用mysqldump + binlog重放、或GTID复制方式迁移，可通过复制状态判断同步是否跟上：
- 执行SHOW SLAVE STATUS\G，重点关注Seconds_Behind_Master值——持续为0表示已追平；数值增大说明延迟加重
- 配合Read_Master_Log_Pos和Exec_Master_Log_Pos对比，确认IO线程是否拉取完成、SQL线程是否执行到位
- 若使用MySQL 8.0+，还可查performance_schema.replication_applier_status_by_coordinator获取更细粒度任务进度
统计已导入的数据行数（适用于mysqldump或LOAD DATA迁移）
对单表大文件导入，可在目标库中定时查询当前行数，与源表比对估算完成度：
- 先在源库执行SELECT COUNT(*) FROM table_name获取总行数（注意：大表慎用，可用EXPLAIN SELECT COUNT(*)估算）
- 在目标库执行相同语句，对比增长趋势；也可用SELECT TABLE_ROWS FROM information_schema.TABLES快速获取近似值（需ANALYZE TABLE更新统计）
- 搭配导入命令加--verbose参数（如mysqlimport）或重定向日志，观察每批次输出的“records inserted”提示
监控系统资源与网络吞吐（通用辅助手段）
迁移本质是I/O和网络密集型操作，资源使用率能间接反映活跃程度：
- 用iostat -x 1观察%util、await，确认磁盘未饱和；用iftop -P 3306看MySQL端口实时流量
- 在目标实例中执行SHOW PROCESSLIST，查找状态为Sending to client（dump中）、Executing（导入中）或Waiting for master to send event（复制中）的线程
- 开启慢查询日志+long_query_time=0，临时捕获卡顿SQL，排查是否因索引缺失或锁表导致迁移变慢
利用工具自带进度反馈（推荐提效方式）
第三方工具通常提供更直观的进度条和预估时间：
- mydumper/myloader：运行myloader -t 4 -d /path/to/dump时默认显示“Thread X: restoring table `db`.`tbl` (X/X rows)”
- Percona XtraBackup：备份阶段用--progress，恢复阶段通过innobackupex --apply-log输出的“Progress”百分比跟踪
- pt-table-sync或gh-ost等在线变更工具，会实时打印“Copying rows X of Y”或“ETA: 2h15m”类信息
不复杂但容易忽略的是定期校验——迁移中途抽样比对几条关键记录的MD5或CHECKSUM，比盲目等结束更可靠。
