xtrabackup是唯一被广泛验证的原生InnoDB热备工具，因其直接拷贝数据文件和redo log并流式追加，全程不锁InnoDB表；而mysqldump --single-transaction仅靠MVCC快照实现“准热备”，对MyISAM仍需全局读锁，且存在长事务阻塞、无binlog位点记录、恢复慢等硬性限制。
mysqldump 不能真正实现热备份，它对 InnoDB 表仅能模拟“准热备”；而 xtrabackup 是目前 MySQL 生产环境中唯一被广泛验证的、原生支持 InnoDB 热备份的开源工具。
为什么 mysqldump --single-transaction 不算真正热备
它依赖事务快照（MVCC）保证一致性，但存在几个硬性限制：
- 只对
InnoDB有效，MyISAM表仍会加全局读锁（FLUSH TABLES WITH READ LOCK），写操作阻塞 - 备份期间长事务未提交，会导致
undo log膨胀、备份变慢，甚至触发Lock wait timeout exceeded - 不备份
binlog位点、GTID、用户权限表（mysql.user等需显式指定）、视图定义、存储过程等元数据 - 导出的是 SQL 文本，恢复时需重放全部语句，大库耗时极长，且索引重建无法并行
xtrabackup 实现热备的关键行为
它直接拷贝 InnoDB 的数据文件（.ibd）和日志（ib_logfile*），通过 redo log 流式追加保证一致性：
- 全程不锁表，读写完全不受影响（InnoDB 表），
MyISAM表仍需短暂全局读锁（但可忽略） - 备份时自动记录
binlog文件名与位置（若开启log-bin），或GTID坐标，方便后续基于时间点恢复 - 支持流式压缩（
--stream=xbstream+gzip）、加密、增量备份、部分备份（指定库/表） - 恢复是物理还原，跳过 SQL 解析和执行，速度比
mysqldump快 3–10 倍（尤其 >100GB 场景）
备份命令差异与典型误用
两个工具的调用逻辑完全不同，混用参数会直接失败：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
mysqldump -u root -p --single-transaction --all-databases > full.sql：输出纯文本 SQL，不可直接用于物理还原 -
xtrabackup --backup --target-dir=/backup/full_$(date +%F) --user=root --password=xxx：生成二进制文件集，必须用xtrabackup --prepare预处理后才能还原 - 误把
xtrabackup备份目录当mysqldump文件 source 进 MySQL：报错ERROR 1064 (42000)，因为内容根本不是 SQL - 用
mysqldump加--master-data=2想替代binlog定位：只能记录备份开始时刻的 binlog 位置，无法覆盖备份过程中产生的新事务
选哪个？看你的恢复 SLA 和数据规模
如果单库小于 5GB、允许分钟级停机、无主从同步需求，mysqldump 足够轻量、易审计、兼容性好；一旦超过 20GB 或要求 RTO xtrabackup 就是事实标准——但它对运维链路要求更高：必须校验 --prepare 结果、确认 innodb_log_file_size 匹配、避免误删 xtrabackup_checkpoints 文件。很多线上事故，就出在跳过 prepare 直接拷回数据目录这一步。
