一致性必须靠显式控制：锁写、校验、增量追平三者缺一不可；mysqldump不解决迁移期间写入问题，DTS需结构/全量/增量按序启动并严格校验表数、字段顺序、延迟及字符集/sql_mode兼容性。
没有“自动一致”的迁移，一致性必须靠显式控制：锁写、校验、增量追平三者缺一不可。
为什么 mysqldump 导入后大概率不一致
很多人导完 mysqldump 就以为数据齐了，结果上线后发现金额对不上、订单漏单。根本原因是：mysqldump 本身不解决迁移期间的写入问题，而生产库几乎不可能全程停写。
- 即使加了
--single-transaction，也只能保证 InnoDB 表快照一致；含 MyISAM 表或长事务时，SELECT可能读到中间态 - 导入过程单线程执行 SQL，10GB 数据可能耗时 2 小时以上——这期间源库所有新写入都丢失
- 导入后没做校验就切流，
ERROR 1449（DEFINER 用户不存在）、ERROR 1366（字符集隐式转换失败）等错误会静默跳过部分语句，导致数据缺失
DTS 增量同步必须开启三项且按序启动
阿里云 DTS 是目前唯一能将一致性落到分钟级的方案，但它的三类迁移不是可选项，而是强依赖链：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
结构迁移：必须先跑完，否则全量导入时目标库找不到表，报
Unknown database 'xxx'；注意 RDS 会自动过滤掉不支持的参数（如ROW_FORMAT=COMPRESSED），需人工确认外键是否生效 -
全量迁移：DTS 内部用并行
SELECT INTO OUTFILE+LOAD DATA，比mysqldump快 3–5 倍；但若源库max_allowed_packet太小，大字段会截断，需提前调大 -
增量迁移：依赖源库
binlog_format = ROW且binlog_expire_logs_seconds ≥ 迁移总耗时；若设置为 86400（1天），而全量跑了 30 小时，增量通道会因日志被清理而中断
切流前必须验证的三个硬指标
DTS 控制台显示“迁移完成”只是流程结束，不代表数据已对齐。以下三步缺一不可：
- 查表数量：
SELECT COUNT(*) FROM information_schema.tables WHERE TABLE_SCHEMA = 'db_name'，源库和 RDS 必须完全相等 - 验字段顺序：抽样关键表，执行
SELECT MD5(GROUP_CONCAT(COLUMN_NAME ORDER BY ORDINAL_POSITION)) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='orders'，MD5 值必须一致（顺序错会导致 INSERT 字段错位） - 盯延迟：在 RDS 上执行
SHOW SLAVE STATUS\G，确认Seconds_Behind_Master = 0，且IO_Running = Yes、SQL_Running = Yes；只要任一为No，说明增量已断
最容易被忽略的字符集与 sql_mode 兼容性
很多团队校验完行数和 MD5 就切流，结果第二天业务报错。真正坑在细节：
- RDS 默认开启
STRICT_TRANS_TABLES，而本地库可能是NO_ENGINE_SUBSTITUTION；应用若把字符串'abc'插入数字字段，本地库只警告，RDS 直接报ERROR 1366并丢弃整条语句 - 源库用
utf8mb4_unicode_ci，RDS 初始化时若选错成utf8mb4_0900_as_cs，排序和比较行为会变，WHERE name = '张三'可能查不到数据 -
DEFINER问题不会阻断 DTS，但函数/视图在 RDS 上无法执行；必须在结构迁移后手动执行ALTER DEFINER = CURRENT_USER或补上对应用户
这些都不是“迁移工具该管的事”，而是你必须在切流前亲手验证的兼容层。
