mysql备份恢复需按业务选方法：物理备份（冷/热/温）快但要求高，逻辑备份用mysqldump最常用，须加--single-transaction等参数保障一致性，恢复前确认库存在。
服务器维护中备份与恢复 MySQL 数据库，核心是选对方法、保障一致性、留出恢复路径。不能只靠一次全量导出完事，得结合业务可用性、数据量大小和恢复时效要求来定策略。
先确认备份类型和适用场景
物理备份直接复制数据文件，速度快、恢复快，但对运行状态敏感：
- 冷备份：必须停 MySQL 服务，用 tar 打包 datadir 目录（如
/var/lib/mysql），适合低峰期维护或测试环境 - 热备份：服务不中断，推荐用 Percona XtraBackup（InnoDB 引擎首选），支持全量+增量，无需锁表
- 温备份：用 mysqldump 加
--single-transaction参数，对 InnoDB 表基本无锁，但会短暂加全局读锁，适合中小规模生产库
逻辑备份实操要点（以 mysqldump 为主）
这是最常用、最易上手的方式，重点在参数和流程：
- 全库备份命令示例：
mysqldump -u root -p --single-transaction --routines --triggers --all-databases > full_backup_$(date +%F).sql - 关键参数说明：
--single-transaction避免锁表（仅 InnoDB），--routines和--triggers保留存储过程与触发器 - 建议加上压缩：
mysqldump -u root -p --single-transaction db_name | gzip > db_name_$(date +%F).sql.gz - 恢复时确保目标库存在，再执行：
mysql -u root -p db_name 或解压后导入
增量备份靠 binlog，必须提前开启
仅靠全量备份无法应对误删、错更新等细粒度故障，binlog 是实现时间点恢复的基础：
- 检查是否启用：
mysql -e "SHOW VARIABLES LIKE 'log_bin';"，返回ON才有效 - 日常操作中定期刷新日志：
mysqladmin -u root -p flush-logs，生成新 binlog 文件便于归档 - 备份 binlog 文件本身（如
mysql-bin.000001），不是导出 SQL，而是直接复制或 rsync 到安全位置 - 恢复时按顺序重放：
mysqlbinlog mysql-bin.000001 mysql-bin.000002 | mysql -u root -p - 可精准到秒或位置恢复，例如跳过某条误操作：
mysqlbinlog --stop-datetime="2026-08-13 14:22:00" binlog_file | mysql -u root -p
恢复前务必验证备份有效性
很多故障发生在“以为有备份，其实导出失败或权限不足”：
- 检查 SQL 备份文件开头是否有
CREATE DATABASE或USE语句，避免恢复时报“数据库不存在” - 用
head -20 backup.sql快速确认内容是否正常，不是空文件或报错输出 - 定期抽样恢复测试：在隔离环境导入一份备份，验证表结构、数据行数、关键记录是否完整
- 物理备份要核对文件权限：
chown -R mysql:mysql /var/lib/mysql，否则启动失败
