StudyStore 综合实战与进阶路线

综合实战把前面所有局部结论放到同一个生命周期里验证：迁移能否从空实例执行，约束能否抵御坏数据，订单事务能否在并发下守恒，查询计划能否随数据增长保持合理，最小权限、备份和复制能否在故障时真正工作。

一、学习目标

交付完整、不可变且可重放的 Schema 迁移
完成订单、库存、查询与报表闭环
验证并发、死锁、幂等和恢复
落实账户、TLS、备份、复制和监控基线
形成升级、发布、回滚与进阶检查表

二、最终数据模型

核心关系：

customers 1──n orders 1──n order_items n──1 products
products 1──n inventory_movements
orders   1──n audit_events

所有表有稳定主键，邮箱、SKU、请求键有业务唯一约束，数量和金额有 CHECK，关联有外键。订单项保存成交单价，库存流水保存每次变化原因与关联请求，审计事件不替代数据库日志但提供业务追踪。

三、迁移与种子

迁移从 001 开始不可变，记录校验和。种子脚本生成确定性客户、商品、订单分布，包含空集、热门商品、长尾客户、相同时间戳和取消订单。性能数据生成与功能种子分开，避免日常测试加载百万行。

在两个空 9.7.1 实例执行并比较 SHOW CREATE TABLE、对象数量与迁移记录。任何环境差异都先解决，不能继续在漂移 schema 上测试。

四、业务事务

创建订单按稳定商品 ID 顺序锁定或条件更新库存，在同一事务写订单、订单项、库存流水和审计。request_key 保证客户端重试不重复扣减。

测试覆盖库存不足、重复请求、唯一冲突、死锁、连接取消和提交结果不确定。每次失败都检查金额与库存守恒，重试整个事务并设置上限。远程支付不放在数据库事务中，使用明确状态和 outbox/补偿概念扩展。

五、查询与性能

交付查询包括商品搜索、客户订单游标分页、订单详情、每日收入、客户累计消费和库存异常。每条查询保存期望粒度、关键索引和 9.7.1 的 EXPLAIN ANALYZE 基线。

用均匀与倾斜数据验证估算，记录索引空间和写入代价。计划基线用于发现明显退化，不把具体成本数字硬编码成跨环境绝对断言。

六、安全与运维

迁移、应用、只读和复制账户分离，TLS 连接经过验证。应用无 DROP/ALTER 权限，只读账户无法写。秘密不出现在 SQL 仓库和日志。

每日备份、binlog 保留、恢复演练和复制监控对应明确 RPO/RTO。仪表板覆盖业务延迟、错误、连接、长事务、锁、磁盘、复制和备份年龄。每个高优先级告警附运行手册。

七、交付矩阵

发布前执行：

两个空实例重放迁移和种子。
全部结果与约束断言。
双连接隔离、锁与死锁测试。
EXPLAIN ANALYZE 与索引检查。
最小权限允许/拒绝测试。
dump 到第二实例恢复和校验。
GTID 复制写入与追平。
8.4.10 dump 到 9.7.1 的兼容恢复。

所有容器、网络和数据库使用任务专属名称，失败时保存日志后清理。

八、进阶路线

完成 StudyStore 后可选择：

深入优化器、成本模型、Hypergraph Optimizer 与复杂连接；
学习 Group Replication、InnoDB Cluster 与 Router；
建立物理备份、时间点恢复和大规模升级演练；
研究分区、归档、数据治理与隐私；
在保持 SQL 契约测试的前提下接入一种应用驱动。

一次只引入一类复杂度，保留恢复和性能基线。不要以“上了集群”替代正确 schema、短事务和可靠备份。

九、最终验收矩阵

综合项目完成后，用下面的矩阵做一次由另一位操作者执行的验收：

场景	操作	必须观察的结果
全新部署	空实例应用全部迁移	对象定义、版本和校验和一致
数据正确性	加载功能种子与反例	约束拒绝坏数据，汇总金额守恒
并发订单	两连接竞争同一库存	不超卖，死锁能整体重试
权限越界	只读/应用账户执行 DDL	明确拒绝且不泄露秘密
查询退化	加载倾斜和大规模数据	结果一致，计划与扫描量可解释
备份恢复	dump 到全新实例	对象、行数、金额和烟测全部通过
复制中断	暂停副本再恢复	GTID 追平，无静默跳过错误
LTS 迁移	8.4 dump 恢复到 9.7	兼容基线通过，专属对象单独迁移

验收材料包含镜像 digest、迁移校验和、种子版本、会话基线、执行计划、权限结果、备份 SHA-256、恢复耗时与复制状态。只给出截图不够，必须保留可重新执行的命令和 SQL。若结果依赖管理员手工点击或某个旧会话，交付尚未完成。

最后演练停止条件：磁盘空间不足、恢复超出 RTO、复制无法追平、迁移定义漂移或关键查询计划明显退化时，应中止切换并保留旧环境。回滚不是一句“恢复备份”，而是一组已计时、已验证且有数据写入冻结条件的步骤。

验收结束后整理未覆盖风险、负责人和复测日期，避免把“本次通过”误写成永久保证。

十、从知识点到工程契约

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

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

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

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

本篇最重要的能力是“交付完整、不可变且可重放的 Schema 迁移”。能由主键、唯一键、外键、CHECK 或数据类型表达的规则，应优先落到数据库；需要跨聚合或外部系统判断的规则，再由应用和事务协调。不要用注释或约定替代可执行约束。

十一、验证策略与复盘

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

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

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

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

本篇可以用以下目标做验收：完成订单、库存、查询与报表闭环；验证并发、死锁、幂等和恢复；落实账户、TLS、备份、复制和监控基线。把每个目标转换为一条可重复 SQL、一个预期错误或一项恢复检查。若优化后结果正确但计划退化，应把执行计划也纳入回归证据。

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

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

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

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

十二、StudyStore 实验

在全新环境完成完整交付矩阵，保存版本、迁移校验和、查询计划、权限结果、备份校验和、恢复计数、GTID 状态与总耗时。随后故意制造坏迁移、死锁、磁盘压力和副本延迟，按运行手册恢复并复盘。

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

十三、常见错误

综合项目中让环境拥有不同迁移历史
只验证查询结果，不验证约束、计划与并发
死锁和提交不确定时直接重复扣库存
应用账户拥有 DDL 或全局权限
有复制和备份却没有故障切换与恢复演练

十四、练习与自测

画出创建订单事务的锁顺序和失败恢复路径。
为六条关键查询建立结果与计划基线。
完成一次 8.4→9.7 逻辑迁移报告。
按 RPO/RTO 设计备份、binlog 和复制组合。
让另一位操作者只根据运行手册完成恢复。

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

十五、官方资料

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

上一篇：监控、容量规划与日常运维