17370845950

可以，但仅限于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。