--single-transaction仅对InnoDB有效，通过一致性快照避免锁表，但若备份中断（如kill、网络断、磁盘满），会导致SQL不完整，恢复时报ERROR 1064或主键冲突。
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(*) 检查结构与数据量是否匹配，否则等到故障那天才发现备份为空，就只剩重做主从了。
