MySQL 完整学习路线

这是一套面向已有编程基础读者的 MySQL 学习笔记。实验基线固定为 MySQL Community Server 9.7.1 LTS、InnoDB、utf8mb4、严格 SQL 模式和 UTC。贯穿项目 StudyStore 是独立的订单与库存示例库，只通过 SQL 和官方客户端运行，不依赖 Go、ORM 或云服务。

学习数据库不能只追求“这条 SQL 返回了数据”。还要说明约束在哪里、事务何时提交、并发会锁住什么、执行计划为何选择某个索引，以及备份是否真的能够恢复。

一、学习目标

确认 MySQL 9.7.1 LTS、Community Edition 与实验边界
理解 18 篇笔记如何围绕 StudyStore 逐步推进
建立从空实例可重复执行的 SQL 实验方法
把正确性、并发、性能、安全和恢复纳入同一模型
明确 8.4 LTS 兼容与升级验证范围

二、版本与实验基线

服务端：MySQL Community Server 9.7.1 LTS
容器：mysql:9.7.1
存储引擎：InnoDB
字符集：utf8mb4
默认时区：UTC
客户端：镜像内 mysql 与 mysqldump
兼容验证：从 MySQL 8.4.10 逻辑备份后恢复到 9.7.1

连接后立即记录：

SELECT VERSION();
SELECT @@sql_mode, @@time_zone, @@transaction_isolation;
SELECT @@character_set_server, @@collation_server;

本系列不使用 26.7 Early Access，也不把 Enterprise、HeatWave 或云厂商专属能力混入 Community 示例。

三、课程地图

阶段	篇目	完成后能验证什么
环境与建模	1～3	从空实例创建有约束、可迁移的 schema
查询与分析	4～7	写出结果正确、边界明确的查询与报表
性能与并发	8～12	解释索引、执行计划、事务、锁和高级对象
安全与运维	13～17	实施权限、备份、复制、监控与交付演练

章节按依赖递进。索引优化依赖查询语义正确，锁分析依赖事务边界明确，复制和恢复又依赖稳定主键、日志与备份。若跳读，至少先建立第 1～5 篇的环境、类型、约束和写入基线。

四、贯穿数据库

StudyStore 包含：

customers
products
orders
order_items
inventory_movements
audit_events

客户与商品提供主数据，订单和订单项表达聚合，库存流水展示事务与并发，审计记录帮助运维追踪。金额使用 DECIMAL，时间统一 UTC，外键和唯一键保护本地不变量。

项目脚本按迁移、种子、查询和测试分组。每次验证都创建全新临时数据库，按顺序应用迁移，加载确定性数据，再执行断言；不依赖图形客户端或手工点击。

五、学习方法

每个实验都记录五类证据：版本与会话变量、DDL 定义、输入数据、结果或错误、事务和恢复状态。涉及性能时保存 EXPLAIN ANALYZE，涉及并发时使用两个独立连接，涉及运维时在第二个空实例完成恢复。

不要在生产知识库或真实业务实例直接练习 DROP、锁等待、复制切换。所有破坏性实验只针对名称明确的临时容器和 study_store 测试库，并在脚本结束时清理。

六、完成标准

完成系列时，应能从空实例执行 schema 和种子，回答：

为什么每个表需要当前主键与唯一键；
某条查询为何使用或不使用联合索引；
在 REPEATABLE READ 下两个会话会看到什么；
死锁发生后哪一方重试、如何保证幂等；
最小权限账户能做什么、不能做什么；
备份在新实例恢复后如何证明完整。

最终还要完成一次 8.4.10 逻辑备份到 9.7.1 的恢复演练，以及一组主从 GTID 复制验证。

七、从知识点到工程契约

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

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

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

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

本篇最重要的能力是“确认 MySQL 9.7.1 LTS、Community Edition 与实验边界”。能由主键、唯一键、外键、CHECK 或数据类型表达的规则，应优先落到数据库；需要跨聚合或外部系统判断的规则，再由应用和事务协调。不要用注释或约定替代可执行约束。

八、验证策略与复盘

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

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

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

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

本篇可以用以下目标做验收：理解 18 篇笔记如何围绕 StudyStore 逐步推进；建立从空实例可重复执行的 SQL 实验方法；把正确性、并发、性能、安全和恢复纳入同一模型。把每个目标转换为一条可重复 SQL、一个预期错误或一项恢复检查。若优化后结果正确但计划退化，应把执行计划也纳入回归证据。

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

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

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

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

九、StudyStore 实验

启动临时 mysql:9.7.1，记录版本、SQL 模式、时区、字符集与隔离级别。创建空 study_store 后立即删除，确认实验脚本只作用于明确容器和数据库，为后续迁移建立安全边界。

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

十、常见错误

只看到 Query OK 就认为结果、约束和事务都正确
在默认配置未知的实例上比较实验结果
把 8.4、9.7 与 Early Access 功能混成同一基线
直接在真实业务数据库练习锁、DROP 或权限
有备份文件却从未在新实例执行恢复

十一、练习与自测

记录当前实验实例的版本、模式、时区和字符集。
画出 StudyStore 六张表的关系及事务边界。
为四个学习阶段各写一项自动化验收标准。
说明为什么备份成功不等于恢复成功。

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

十二、官方资料

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

下一篇：环境、版本与客户端基线