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

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 必须用与生产环境**完全一致的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 成功率，那备份文件只是磁盘上的幻觉。