备份怎么恢复
恢复逻辑备份就是把 SQL 文本重新喂给服务器，常见三种方式：命令行重定向导入、交互客户端里的 source 命令、或直接管道连接。恢复的瓶颈通常在写入与日志：几十 GB 的文本可能跑上数小时，需要提前留出维护窗口，并在导入方式、字符集与是否写日志之间做取舍。导入前先确认目标库是否存在、字符集是否一致。
基本信息
| 命令行导入 | mysql -uroot -p 库名 < backup.sql |
|---|---|
| 客户端内导入 | 先选库再执行 source 加文件路径 |
| 大库提速 | 视复制拓扑决定是否临时关闭日志写入 |
| 前置条件 | 目标库存在、字符集一致、磁盘空间充足 |
| 耗时参考 | 与数据量线性相关，几十 GB 常需数小时 |
| 关键核对 | 导入后比对表数量、行数与关键业务数据 |
典型使用场景
- 误删数据后的定向恢复：先恢复到临时实例，再抽取需要的表
- 版本升级回退：把备份回灌到旧版本实例
- 新环境初始化：把生产备份脱敏后导入测试环境
- 主从重建：在从库上导入主库备份后重新建立复制
- 演练验收：定期做恢复演练，验证备份可用性与耗时
- 数据迁移：用逻辑备份跨实例搬移数据
恢复示例
恢复示例
mysql -uroot -p --default-character-set=utf8mb4 appdb < appdb_backup.sql # 指定库并统一字符集
mysql -uroot -p < all_backup.sql # 全库文件自带建库语句，不用指定库
mysql -uroot -p --init-command="SET SESSION sql_log_bin=0" appdb < big.sql # 确认复制拓扑不受影响再关日志写入
# 客户端内恢复：先 USE appdb; 再 SOURCE /data/backup/appdb_backup.sql;导入后核对
导入后核对
SHOW TABLES FROM appdb; # 表数量是否与备份一致
SELECT COUNT(*) FROM appdb.orders; # 关键表行数抽查
SELECT COUNT(*) FROM information_schema.tables # 比对对象总数
WHERE table_schema='appdb';
SHOW GRANTS FOR 'app'@'10.0.%'; # 账号授权不在数据备份里，需单独恢复导入方式对照
| 方式 | 命令要点 | 适用场景 |
|---|---|---|
| 重定向导入 | mysql 库名 < 文件 | 单库或单表文件，最常用 |
| 客户端内执行 | 先选库再执行文件路径 | 需要边看输出边导入 |
| 管道连接 | 导出输出直接管道给导入命令 | 同机迁不落地文件 |
| 拆表分别导入 | 大表单独导出再导入 | 便于定位失败点与并行处理 |
| 关闭日志写入 | 会话级关闭二进制日志 | 确认拓扑不受影响后使用 |
| 单独恢复授权 | 账号授权不随数据备份 | 需另行准备授权脚本 |
关闭二进制日志写入会让该实例的 GTID 集缺失，在复制拓扑里的库上执行会造成主从不一致，务必先确认拓扑再决定，不要在从库上随手关闭。
恢复用哪个账号很关键：长期用管理账号恢复会掩盖权限问题，等应用账号连不上才发现授权没恢复，建议导入完成后立刻用业务账号验证一次读写。
恢复本质是覆盖写：整库备份文件自带建库语句，在已有数据的目标库上导入会与现有对象冲突，误导入生产库等于把线上数据覆盖掉，导入前必须确认目标。
恢复检查清单
- 确认备份文件完整性，必要时先在临时实例试恢复
- 确认目标实例版本、字符集与源端一致或兼容
- 预留磁盘空间与维护窗口，导入前暂停相关写入
- 导入过程保留日志，便于失败后从断点定位
- 导入后核对表数量、行数与关键业务抽样数据
- 单独恢复账号授权、存储程序与定时任务
恢复耗时是备份策略的一部分：如果一次恢复要六个小时，那么恢复时间目标就写不进一小时。定期演练并把实际耗时记录下来，扩容与选型才有依据。