mysqldump 加 --single-transaction 能否保证一致性？
可以，但仅限于 InnoDB 表，且要求事务隔离级别为
REPEATABLE READ（MySQL 默认）。它通过在 dump 开始时启动一个快照事务，后续所有表读取都基于该一致性视图，避免中途写入干扰。
常见错误现象：
mysqldump导出后发现某些行缺失或状态不一致，往往是因为混用了 MyISAM 表（不支持事务），或导出期间执行了
DROP TABLE/
ALTER TABLE等隐式提交操作，导致快照失效。 务必确认源库所有表均为 InnoDB：用
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db';避免在 dump 过程中执行 DDL；若必须，改用
--lock-all-tables（会锁全库读） 不推荐依赖
--skip-lock-tables，它在非事务引擎下完全无法保证一致性
使用 pt-table-checksum 校验迁移后数据是否一致
这是 Percona Toolkit 中专用于主从/迁移后数据比对的工具，原理是分块计算校验和并逐块比对，不依赖全量 SELECT，适合大表。
使用场景：迁移完成后，快速定位哪张表、哪个主键范围存在差异，而非简单“行数相等就完事”。它能绕过时间字段、浮点精度等干扰项，只比对业务关键列。
需在源库开启 binlog（log_bin = ON），且用户要有
REPLICATION CLIENT和
PROCESS权限 校验前确保目标库已停写，否则 checksum 结果不可信 运行示例：
pt-table-checksum --host=source_host --databases=your_db --no-check-binlog-format，然后用
pt-table-sync修复差异
GTID 模式下迁移要不要关掉 gtid_next？
不需要，也不应该手动干预
gtid_next。GTID 自动保证事务在目标库重放时不会重复或跳过，前提是迁移过程不引入外部事务 ID 冲突。
容易踩的坑：用
mysqldump --set-gtid-purged=ON导出时，若目标实例已有 GTID，且
gtid_purged不包含源库的 UUID，导入会报错
ERROR 1840 (HY000)。 安全做法：导出时加
--set-gtid-purged=AUTO（默认），导入前在目标库执行
RESET MASTER清空 GTID 集合（仅限全新目标库） 若目标库已有数据且需保留 GTID 历史，改用
--set-gtid-purged=OFF，但需确保应用层不依赖 GTID 追踪位点 切勿在导入 SQL 中手动添加
SET GTID_NEXT='...'—— mysqldump 已处理，重复设置会破坏 GTID 连续性
逻辑迁移 vs 物理迁移：什么情况下必须选 xtrabackup？
当单表超 100GB、或要求停机窗口小于 5 分钟时，
mysqldump几乎不可行 —— 它本质是串行 SELECT，网络+解析+重放耗时太长，且期间无法承受写入压力。
xtrabackup是唯一成熟的物理热备方案，它直接拷贝 InnoDB 数据文件 + redo log，并在恢复时重放未提交事务，最终达到与源库完全一致的状态。 必须关闭目标库再恢复（
xtrabackup --copy-back后需
chown mysql:mysql并重启） 跨版本迁移风险高：xtrabackup 2.4 不兼容 MySQL 8.0 的数据字典格式，须严格匹配版本 备份时若启用了加密（
innodb_encrypt_tables），恢复时需提前配置相同密钥环，否则报错
Tablespace is encrypted实际中最容易被忽略的是字符集与排序规则的隐式转换。哪怕
SHOW CREATE TABLE看起来一样，
utf8mb4_0900_as_cs和
utf8mb4_unicode_ci在 ORDER BY 或唯一约束上行为不同，可能导致迁移后查询结果错乱或插入失败。迁移前后务必核对
character_set_database和
collation_database。
