mysqldump 不适用于大库备份，因其锁表、高内存占用、无并行与压缩、恢复慢且易出错；推荐使用 xtrabackup 物理热备，支持并行、压缩、增量及可靠恢复。
单靠 mysqldump 备份大库（>50GB）基本不可行——它会锁表、吃内存、耗时数小时，且恢复过程极慢。必须换物理备份或带并发/压缩的专用工具。
为什么 mysqldump 在大库上会崩
它本质是“查一遍、写一遍”，所有数据都走 SQL 解析和文本序列化：
-
mysqldump不支持真正意义上的并行导出（即使加--single-transaction，InnoDB 仍需一致性快照，长事务会拖慢备份） - 默认不压缩，网络/磁盘 I/O 成瓶颈；100GB 库导出文件常超 80GB
- 备份期间若发生主键冲突、字符集不一致、视图定义缺失等问题，
mysql恢复时直接报错中断 - 无法跳过日志表、历史归档表等非核心数据，白白浪费时间
xtrabackup 是当前最稳的大库备份方案
Percona XtraBackup 直接读取 InnoDB 的物理页（.ibd 文件），跳过 SQL 层，支持真正热备：
- 用
--parallel=4并行读取多个表空间，提速 2–3 倍 - 加
--compress --compress-threads=2边读边压，最终备份体积减少 60%+ - 增量备份只记录变更页，
--incremental-basedir指向上一次全量或增量目录即可 - 必须搭配
--prepare阶段回滚未提交事务、前滚已提交但未刷盘的日志，否则无法启动 MySQL
示例命令（全量+压缩+并行）：
xtrabackup --backup \ --target-dir=/backups/full_$(date +%Y%m%d) \ --parallel=4 \ --compress \ --compress-threads=2 \ --user=root --password=xxx
物理拷贝仅限极特殊场景，且风险极高
直接 cp -r /var/lib/mysql/mydb /backups/mydb_$(date +%Y%m%d) 看似最快，但：
- 必须确保 MySQL 已
systemctl stop mysqld——冷备，业务完全中断 - InnoDB 表空间若启用了
innodb_file_per_table=OFF，所有表共用ibdata1，无法单独拷贝某库 - 恢复时需严格匹配 MySQL 版本、配置项（如
innodb_page_size），否则启动失败报Invalid log block checksum - 没做
FLUSH TABLES WITH READ LOCK+SHOW MASTER STATUS记录 binlog 位点，就无法做主从同步
真正落地时最容易被忽略的三件事
一是备份后不校验：xtrabackup --verify-read 或至少用 innobackupex --apply-log-only 模拟 prepare 过程；
二是没清理旧备份：find /backups -name "full_*" -mtime +7 -delete 必须写进定时脚本；
三是权限没对齐：备份目录属主必须是 mysql 用户，否则恢复时 chown -R mysql:mysql /var/lib/mysql 缺一不可。
