可以，但仅限于InnoDB表且需REPEAtable READ隔离级别；它通过快照事务保证一致性，混用MyISAM或执行DDL会破坏该一致性。
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。