mysqldump 不支持快照级断点续传，--single-transaction 仅提供导出起点的一致性快照，无法记录进度锚点；真正可用的是 mydumper + metadata 位点，或主键分片配合 progress.log 实现可验证断点。
mysqldump 本身不支持快照级断点续传，所谓“MySQL快照技术”在迁移语境下常被误读——真正可用的是 --single-transaction 提供的一致性快照，但它只是导出起点的事务快照，不是可中断/恢复的进度锚点。靠它实现断点续传会失败。
为什么 --single-transaction 不能当断点用
这个参数只保证导出开始那一刻所有表处于一致状态（通过 START TRANSACTION WITH CONSISTENT SNAPSHOT），但整个导出过程仍是单一流式输出：mysqldump 不记录“已导出到哪张表第几行”，网络中断后重跑，只能从头再来。即使导出中途挂了，目标端也无从知道哪些表、哪些数据已写入。
- 错误现象：重试时重复导入，主键冲突或
Duplicate entry报错 - 本质限制：
mysqldump输出无结构化位点标记，无法定位断点 - 兼容性坑：MySQL 5.7+ 支持该参数，但云数据库（如阿里云 RDS）可能因缺失
REPLICATION CLIENT权限直接报错
真正能落地的“快照+断点”组合：mydumper + metadata 位点
mydumper 才是把快照和断点结合得最实的工具——它导出时生成 metadata 文件，里面明确记录 SHOW MASTER STATUS 的 File 和 Position，这才是可校验、可续传的快照位点。
- 导出命令必须带
--snapshot（默认开启）和--trx-consistency-only，确保每个表文件都基于同一快照 - 生成的
/backup/db1/metadata内容类似：Started dump at: 2026-06-17 02:15:22+SHOW MASTER STATUS:+mysql-bin.000042\t123456789 - 迁移中断后，先检查目标库哪些表已存在且非空：
SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='db1' - 重试用
myloader --resume，它只跳过非空表，但**不校验该表是否导自同一快照**——所以必须人工比对metadata里的位点和目标库当前SHOW MASTER STATUS（如果是从库）或源库历史位点
大表分片导出：用主键范围替代“快照”的粗粒度断点
当 mydumper 仍不够细（比如单表 200GB），就得放弃“全库快照”思路，改用主键分片——每段导出都是独立快照，断点就是上一个成功分片的最大 id。
- 前提：表必须有单调递增、无空洞的整型主键（
id），否则BETWEEN切片会漏或重 - 导出命令示例：
mysqldump -u user -p -h src db1 table1 --where="id BETWEEN 100000 AND 199999" > table1_100k-199k.sql - 每次成功后，立刻写入
progress.log：echo "table1:100000-199999:success" >> progress.log，并用sync刷盘 - 脚本重启时，读
progress.log跳过所有:success行，只处理未完成区间——这才是可验证、可审计的断点
最容易被忽略的校验环节：位点 ≠ 数据一致
哪怕 metadata 里位点对得上、progress.log 里分片全标记 success，也不代表数据没丢。因为：
-
myloader --resume只看表是否存在，如果某表导入一半失败、留下空表，它就直接跳过 → 数据全丢 - 主键分片中，若某段导出时源表被并发修改（如
DELETE或UPDATE id），BETWEEN会漏掉变更后的行 - 字符集转换、时区差异、隐式类型转换（如
datetime存为字符串）会让CHECKSUM TABLE失效，必须抽样SELECT * ORDER BY id LIMIT 100 OFFSET N比对
