迁移前必须确认的4个mysql实例状态：binlog开启且格式为row；源库用户具备select、replication slave、replication client权限；server_id已设置且唯一；源库版本不高于目标rds支持的最高版本。
迁移前必须确认的 4 个 MySQL 实例状态
云平台 DTS 对源库不是“来者不拒”，很多迁移卡在第一步，其实是源库没达标。
-
binlog必须开启，且格式为ROW（STATEMENT或MIXED会丢数据） - 源库用户需有
SELECT、REPLICATION SLAVE、REPLICATION CLIENT权限，缺一不可 - 确保
server_id已设置且唯一（DTS 会校验，重复或为 0 直接报错Invalid server_id） - 若用 RDS 作为目标，注意源库版本不能高于目标 RDS 支持的最高版本（例如阿里云 MySQL 5.7 RDS 不接受 8.0 源库全量迁移）
DTS 全量 + 增量迁移时，为什么一直卡在“增量同步中”不动
这不是卡住，是 DTS 在等源库产生新 binlog。如果源库长时间无写入，增量位点不会推进，控制台就一直显示“同步中”。
- 检查源库是否真有写入：执行
SHOW MASTER STATUS，对比 DTS 任务详情页里的“当前同步到的位点”，看File和Position是否在变 - 若无业务写入，可手动触发一条
INSERT INTO test_table VALUES (NOW())，观察位点是否更新 - 注意：DTS 增量拉取依赖
binlog_expire_days，该值太小（如设为 1）会导致 binlog 被清理，任务报错Could not find first log file name in binary log index file
遇到 ERROR 1045: Access denied for user 的真实原因和解法
这个错误看起来是密码错了，但 DTS 场景下大概率不是密码问题，而是权限或网络路径不对。
- 先确认 DTS 服务端 IP 是否在源库白名单里（公有云常忽略这点，DTS 不是从你本地 IP 连，而是从云厂商指定网段发起连接）
- 检查用户 host 是否为
%或具体 DTS 所在网段（'dts_user'@'10.100.%'是常见配置，'dts_user'@'localhost'一定失败） - MySQL 8.0+ 用户默认认证插件是
caching_sha2_password，部分老版 DTS 不兼容，需改用mysql_native_password：ALTER USER 'dts_user' IDENTIFIED WITH mysql_native_password BY 'xxx';
大表迁移慢、DTS 任务延迟高，怎么调
不是所有参数都能调，DTS 控制台只暴露有限选项，关键要理解它背后的行为逻辑。
- 全量迁移并发线程数（
MaxThreadCount）默认 8，对 SSD 云盘可提到 16–32，但超过 32 反而因锁竞争变慢 - 单表切片大小（
SplitSize）影响内存占用，设太大（如 500MB）易触发 OOM；设太小（如 10MB）则建太多临时连接，建议 50–100MB - 目标库若开了
innodb_flush_log_at_trx_commit=1，每条 INSERT 都刷盘，会严重拖慢增量同步速度；临时改为2可提速，但要注意故障时最多丢 1 秒事务
真正难处理的是跨地域迁移——比如从 IDC 到华东 1，网络 RTT 高、丢包率波动，这时 DTS 自身重试机制会频繁触发，延迟毛刺明显。没有银弹，只能靠专线或压缩传输（开启 DTS 的“压缩传输”开关，对 CPU 有 10%~15% 开销，但带宽节省可达 40%）。
