备份、恢复、导入与迁移

备份策略由恢复目标定义：能恢复到哪里、允许丢多少数据、多久恢复完。一个 dump 文件只有在独立实例成功恢复、校验并满足权限和时间目标后，才算可用备份。本篇以逻辑备份演示可重复流程和 8.4→9.7 兼容验证。

一、学习目标

区分逻辑、物理、完整与增量备份
使用一致性选项生成 InnoDB 逻辑备份
保护、校验并记录备份元数据
在全新实例恢复和验证
完成 8.4.10 到 9.7.1 的逻辑迁移演练

二、RPO、RTO 与备份类型

RPO 是可接受数据丢失窗口，RTO 是可接受恢复时间。每日逻辑备份无法自动满足分钟级 RPO；还需要二进制日志或复制。mysqldump 可移植、可读，适合中小库与迁移；大库物理备份恢复更快，但工具、版本和存储要求更高。

先估算数据量、变化率、恢复带宽和验证时间，再选择组合。复制不是备份：误删会复制到副本，勒索或权限事故也可能同时影响。

三、一致性逻辑备份

对 InnoDB：

mysqldump   --single-transaction   --routines --triggers --events   --set-gtid-purged=OFF   --databases study_store > study_store.sql

--single-transaction 在事务开始时获得一致性快照，期间避免执行会破坏一致性的 DDL。非事务表不享受相同保证。是否包含账户、程序对象和 GTID 取决于恢复目标，不能复制一条命令覆盖所有场景。

四、保护与元数据

备份旁保存：

服务端版本与镜像 digest；
schema 迁移版本；
开始/结束时间、退出码与大小；
SHA-256；
包含对象和排除项；
加密、密钥和保留策略。

先检查命令退出码再生成“成功”标记。备份文件含个人信息和凭据风险，应加密、最小权限存储并测试密钥恢复。校验和检测损坏，不证明逻辑完整。

五、恢复与验证

恢复到新实例而不是覆盖原库：

mysql < study_store.sql

恢复后检查迁移版本、表/视图/触发器数量、关键行数、外键、金额汇总和抽样业务查询。重新创建最小权限账户，验证应用烟测。记录实际耗时并与 RTO 比较。

仅运行 mysql 返回 0 不够；dump 可能排除了对象，字符集和 SQL 模式也可能改变结果。

六、8.4 到 9.7 迁移

官方支持从 8.4 LTS 升级到下一 LTS 9.7，但迁移前仍要阅读移除、保留字、默认值和认证变化。本系列使用逻辑路径：

在 mysql:8.4.10 创建兼容 StudyStore。
运行升级检查与完整测试。
生成带版本元数据的逻辑备份。
恢复到空 mysql:9.7.1。
重跑 schema、查询、事务和权限烟测。
只在验证后切换，保留回退窗口。

9.7 专属对象如 JSON Duality 不进入 8.4 备份基线。

七、从知识点到工程契约

本篇 SQL 最终要运行在长期存在的 schema、连接和事务中，而不是只在一个临时查询窗口里得到一次正确结果。先写清输入表与行数、会话设置、事务边界、允许的锁、期望结果和失败后的状态，再决定使用约束、查询、索引、存储对象还是运维命令。数据库行为同时受到版本、隔离级别、字符集、统计信息和并发会话影响，示例必须把这些前提显式化。

可以用以下顺序把知识点落到 StudyStore：

在全新数据库按迁移顺序建立最小 schema，保存 SHOW CREATE TABLE 与关键会话变量。
加入一个与“有 dump 文件便宣称备份完成，从不恢复验证”相关的反例，记录错误码、SQLSTATE、事务是否仍可用以及数据是否改变。
为正常、空集、边界值、重复值和并发冲突准备确定性种子，不依赖手工残留数据。
对读查询检查结果集和 EXPLAIN ANALYZE；对写操作同时检查受影响行数、约束、提交与回滚。
最后才讨论性能优化。索引和参数调整必须有执行计划、等待事件或容量数据支持，并保留变更前基线。

审查数据库设计时至少回答四个问题：谁能写，哪条约束保护不变量，事务在哪一层结束，失败后如何恢复。MySQL 能保证声明范围内的事务和持久性，却不会替应用补上缺失约束、幂等键、备份演练或最小权限。只要这些问题没有明确答案，就不要把一次成功执行当成生产方案。

本篇最重要的能力是“区分逻辑、物理、完整与增量备份”。能由主键、唯一键、外键、CHECK 或数据类型表达的规则，应优先落到数据库；需要跨聚合或外部系统判断的规则，再由应用和事务协调。不要用注释或约定替代可执行约束。

八、验证策略与复盘

验证分为 schema、数据、并发和恢复四层。schema 层检查定义与会话基线；数据层断言结果和约束；并发层至少用两个独立连接观察锁与隔离；恢复层在新实例重放迁移、备份与恢复。只看客户端显示“Query OK”不能证明结果正确，更不能证明在另一组数据和并发时仍正确。

建议保存下面的实验记录：

项目	需要记录的证据
版本	`SELECT VERSION()` 与镜像标签
会话	sql_mode、time_zone、事务隔离与字符集
输入	schema 版本、种子行数和参数值
输出	结果集、受影响行数、警告、错误码与 SQLSTATE
性能	执行计划、实际行数、耗时与等待
恢复	COMMIT/ROLLBACK 结果、备份校验和与恢复行数

每组脚本都应能在空数据库从头执行，并通过显式断言退出非零。涉及权限时分别用管理员和最小权限账户连接；涉及锁时设置有限等待，避免测试永久挂起；涉及复制时等待 GTID 状态而不是固定 sleep。清理只删除本次创建的临时容器、网络和数据库。

本篇可以用以下目标做验收：使用一致性选项生成 InnoDB 逻辑备份；保护、校验并记录备份元数据；在全新实例恢复和验证。把每个目标转换为一条可重复 SQL、一个预期错误或一项恢复检查。若优化后结果正确但计划退化，应把执行计划也纳入回归证据。

发布前再从三个方向反向审查：把数据量放大两个数量级，判断扫描、锁和日志是否仍可控；让两个会话以最不利顺序并发，判断约束和事务是否仍保护不变量；让执行在任意一步失败，判断备份、回滚或幂等键能否恢复。只在十几行数据和单连接中成功的 SQL 仍只是功能草稿。

最后把脚本交给一个只知道镜像版本和入口命令的干净环境执行。脚本不得依赖图形客户端自动设置、个人默认数据库或先前会话变量；所有对象名、字符集、事务和预期错误都应明确。对仅用于说明、不可直接执行的片段要标注上下文，避免把省略条件的示意 SQL 当作完整迁移。

还要保存一份“结果为什么可信”的说明：约束证明哪些坏数据无法进入，事务证明哪些变化共同提交，执行计划证明访问了哪些行，权限测试证明哪些身份无法越界，恢复演练证明故障后能重新得到可用状态。这五类证据缺一时，都应在结论旁写明限制。数据库实验的价值不只是得到答案，而是让另一位操作者在不同机器、不同时间仍能重现同一判断。

若结论依赖当前数据分布或配置，应把适用范围写在 SQL 旁，并安排数据增长或版本升级后的复测条件；不要把一次测量永久固化为规则。

九、StudyStore 实验

在 9.7.1 生成 StudyStore dump，校验后恢复到第二个空实例并比较关键计数与金额。再从 8.4.10 创建兼容数据、dump、恢复到 9.7.1，运行相同烟测并记录不兼容项和总恢复时间。

完成本节后，不要只保存代码或 SQL。请同时保存执行命令、关键输出和失败案例；学习笔记真正有价值的部分，是能够说明输入、状态变化、输出以及失败后的恢复方式。

十、常见错误

有 dump 文件便宣称备份完成，从不恢复验证
忽略 mysqldump 退出码或把错误输出混入 SQL
备份未加密且权限比在线库更宽
把复制副本当作误删和勒索的唯一备份
跨 LTS 恢复后不重跑应用与权限测试

十一、练习与自测

为 StudyStore 定义 RPO、RTO 和备份组合。
故意截断 dump，验证校验和与恢复失败。
写恢复后的行数、金额和对象断言。
列出 8.4→9.7 切换与回退必须保留的证据。

自测时应在干净的临时目录或临时数据库中重新执行，而不是依赖上一节遗留的状态。如果结果与预期不同，先记录实际输出，再缩小问题范围。

十二、官方资料

版本行为与二手文章不一致时，以本系列固定版本的官方文档、命令输出和可重复测试结果为准。

上一篇：用户、角色、权限与安全下一篇：复制、GTID 与高可用