mysqldump 备份时为什么加 --single-transaction
却仍可能不一致
这个参数只对 InnoDB 表有效，它通过开启一致性快照避免锁表，但前提是整个备份过程必须在同一个事务中完成。如果备份中途被 kill、网络中断或磁盘满，
mysqldump可能只写入部分 SQL，恢复时会报错
ERROR 1064或主键冲突。 务必配合
--routines --triggers --events才能完整导出存储过程和事件调度器 不要用
SELECT INTO OUTFILE替代
mysqldump做全库备份——它不导出建表语句、权限、字符集等元数据 大库（>50GB）建议用
--skip-lock-tables+
--single-transaction，但要确认没有 MyISAM 表，否则非事务表仍会被锁
如何用 mysqlpump
替代 mysqldump
提升并发备份速度
mysqlpump是 MySQL 5.7+ 提供的并行逻辑备份工具，支持按库、按表、按引擎分片导出，比单线程
mysqldump快 2–5 倍，尤其适合多核服务器。 启用并行：加
--default-parallelism=4（数值建议 ≤ CPU 核数 × 0.8） 排除系统库：
--exclude-databases=mysql,information_schema,performance_schema注意兼容性：
mysqlpump不支持 MySQL 5.6 及更早版本，恢复时也必须用同版本或更高版
mysql客户端
mysqlpump --user=root --password --host=localhost \ --default-parallelism=4 \ --exclude-databases=mysql,information_schema \ --set-gtid-purged=OFF \ --skip-definer \ > backup_$(date +%Y%m%d_%H%M%S).sql
物理备份选 Percona XtraBackup
还是 mysqlbackup
二者都支持热备、增量、压缩和流式传输，但关键区别在于开源协议与企业依赖：
Percona XtraBackup完全开源（GPL），适配 MySQL、Percona Server、MariaDB，社区活跃，
xtrabackup --backup后可直接
--prepare恢复
mysqlbackup（MySQL Enterprise Backup）需商业许可证，集成度高（如自动识别 MEB 加密密钥），但无法用于 MariaDB 或 Percona Server 若使用 GTID，
xtrabackup从 8.0.30 起才原生支持
--gtid参数；旧版需手动解析
xtrabackup_binlog_info文件补位
恢复时执行 source
报错 Unknown command
怎么办
这是最常见的 SQL 文件导入失败原因：备份文件里混有
mysqldump自动生成的元命令（如
/*!40101 SET ... */或
\c），而
mysql客户端默认不解析这些。 正确做法是用
mysql命令行直接导入：
mysql -u root -p database_name如果必须用
source，先登录后执行：
mysql> source /path/to/backup.sql;，且确保该 SQL 文件不含 shell 脚本头（如
#!/bin/bash）或 Windows CRLF 换行符 遇到
ERROR 1840（GTID state mismatch），说明目标实例已启用 GTID 但备份未关闭
--set-gtid-purged，恢复前需加
SET @@GLOBAL.GTID_PURGED='';或用
--set-gtid-purged=OFF重备 备份不是“设好 cron 就完事”的操作。真正难的是验证——每次备份后必须用
mysql -e "SHOW TABLES;"和随机抽样
SELECT COUNT(*)检查结构与数据量是否匹配，否则等到故障那天才发现备份为空，就只剩重做主从了。
