MySQL备份需按数据量、RTO/RPO、引擎类型和运维能力选型：mysqldump适用于50GB以下InnoDB库，须加--single-transaction；XtraBackup支持InnoDB热备但要求版本严格一致且必须--prepare；cp冷备仅限停库后MyISAM全量复制；binlog是实现秒级恢复的必要补充。
MySQL备份方式不是“选一个就行”，而是得看你的数据量、RTO/RPO要求、引擎类型和运维能力——mysqldump在50GB以下表里够用，超过这个量级再硬上就容易卡住或超时；Percona XtraBackup能热备InnoDB大库，但MyISAM表得停写；直接cp复制数据目录看似快，但没停库就拷，恢复出来大概率报错。
什么时候该用 mysqldump
它适合需要可读SQL、跨版本迁移、或者只备份几张核心表的场景。不是万能，但够轻量。
- 必须加
--single-transaction（InnoDB）或--lock-tables（MyISAM），否则备份期间写入可能丢失或不一致 -
--quick要始终开启，避免大表查询把内存撑爆 - 想只导结构不导数据？用
--no-data；只导数据不导建表语句？用--no-create-info - 备份单表比全库更安全：命令里明确指定
database_name table_name，别依赖SHOW TABLES动态拼接，表名含特殊字符时容易出错
Percona XtraBackup 的真实使用门槛
它不是装完就能跑的“黑盒工具”，几个关键点不处理好，备份文件根本没法恢复：
- 必须用与生产环境**完全一致的MySQL版本**，哪怕小版本号差一个（比如 8.0.33 vs 8.0.34），
xtrabackup --prepare都可能失败 - 备份后一定要执行
--prepare（应用redo日志），否则直接拷回去启动会报Tablespace is not found - 增量备份依赖上一次全量备份的
xtrabackup_checkpoints文件，删了或路径错，整个链就断了 - 不支持加密表空间（
ENCRYPTION='Y'）的备份，遇到就报错退出，得提前检查INFORMATION_SCHEMA.INNODB_TABLESPACES
物理复制（cp/rsync）的致命前提
这不是“快捷方式”，而是高风险操作——只有满足全部条件才可考虑：
- 数据库已执行
FLUSH TABLES WITH READ LOCK，且锁未被其他连接释放 - 确认所有表都是 MyISAM 引擎（InnoDB 表用
cp拷出来无法启动） - 操作系统、文件系统、MySQL datadir 路径三者完全一致，否则
ibdata1和.ibd文件对不上 - 备份完立刻
UNLOCK TABLES，锁太久会导致业务写请求堆积超时
别忽略二进制日志（binlog）的配合价值
单独任何一种备份都做不到“精确到秒级恢复”，binlog 是补缺口的关键：
- 恢复流程固定为：先还原最近一次全量备份 → 再用
mysqlbinlog回放从备份时间点到故障前的日志 - 务必确认
binlog_format = ROW，STATEMENT格式在某些函数（如NOW()、UUID()）下无法精确重放 -
expire_logs_days设太小（比如默认7天），可能刚发生误删，binlog 已被自动清理 - 备份脚本里漏掉
FLUSH LOGS，会导致最后一个 binlog 文件没被归档，恢复时缺最后一段
真正难的不是选工具，而是搞清你能不能承担某次备份失败的后果——比如没测过恢复流程，就等于没备份；比如用了 XtraBackup 却没验证 --prepare 成功率，那备份文件只是磁盘上的幻觉。
