查询线 · 读
READ · 从数据里问出结论
- 单表 SELECT / WHERE / ORDER
- JOIN：内、左、自连接
- 聚合 + GROUP BY + HAVING
- 子查询 / 窗口函数
- 用真实业务问题收口
每一问都落在学生自己身上：我这学期选了几门课、班上谁缺勤最多、哪门课均分最低。
数据库课最容易上成「SQL 语法背诵 + 范式定义默写」。但只要整学期只瞄准一个真实在用的库—— 你平台上跑着的那个——学生的每一条 SELECT 都能看见结果，每一次建索引都能听见速度变化。
SELECT s.name, COUNT(e.course_id) AS 选课数, ROUND(AVG(e.score),1) AS 均分 FROM students s JOIN enrollments e ON s.id = e.student_id WHERE e.term = '2026-秋' GROUP BY s.name ORDER BY 选课数 DESC LIMIT 5;
| name | 选课数 | 均分 |
|---|---|---|
| 林可为 | 9 | 92.3 |
| 赵一鸣 | 8 | 88.7 |
| 周小满 | 8 | 86.1 |
| 陈迟 | 7 | 85.4 |
课堂用法：同一句 SQL，点一下建索引，1.84 秒变 0.02 秒——数据库课最该让学生亲眼看到的一幕。
数据库是一门「说了不算、跑出来才算」的课。四条规矩，直接决定学生是在背语法还是在做工程。
整学期只用你平台上那批真实表（脱敏副本）：学生、课程、选课、采集事件。第 1 周的 SELECT 和第 15 周的分库分表，查的是同一批数据，认知才连得起来。
下课时学生手里必须有一个能跑出结果的 .sql 文件，或者一张 ER 图、一份执行计划截图。不是笔记，是可被再次执行的产物。
现场写出外键冲突、唯一键重复、死锁，全班一起读报错。把 EXPLAIN 当 X 光片讲——数据库不是黑盒，是账本 + 仓库，要能被看穿。
给平台后端做一次真实的表结构评审与索引优化，在大屏上量出前后差。「这条索引是我加的」，比任何课后题都有说服力。
会查（读）、会设计（写）、能在出问题时救回来（守）。多数课程只讲前两条，第三条才是学生进公司后第一周就要用的。
每一问都落在学生自己身上：我这学期选了几门课、班上谁缺勤最多、哪门课均分最低。
范式不先讲定义，而是从「一份 Excel 存了所有东西」的痛点倒推出来。
期中给平台后端做一次表结构评审与索引优化，把大屏上的慢查询从 2 秒打到 20 毫秒——学生加的索引真上线。
数据库课最怕「老师敲一句、学生抄一句」。这六个动作都指向同一件事：让结果自己说话。
先甩出一张结果集截图：「这就是我要的答案，你把它写出来。」逆向比正向好学，学生一上来就在解决问题，而不是记语法。
现场版 · 先亮「这学期谁选课最多」的结果表，倒逼学生自己写出 GROUP BY。
两张一万行的表不加连接条件，看着行数从 1 万变 1 亿、磁盘告警。这一炸，JOIN 条件这辈子不会忘。
现场版 · 行数飙到 1 亿、风扇拉满的那 3 秒——比讲十分钟笛卡尔积定义都管用。
先给一个没有主键、全是 VARCHAR、日期存成字符串、索引乱加的库，让学生跑一遍又慢又错；再让他们亲手重建成规范结构。
现场版 · 发一个「学生表里塞了整张课表」的库，日期存成 '2026/9/1号' 这样的文本。
每句 SQL 提交前必须点一次执行计划，并能口头解释「为什么慢」。这是从背语法跨到做工程的分水岭。
现场版 · 口头追问：「扫了 120 万行，返回只有 37 行——中间发生了什么？」
学生把 SQL 与耗时提交到 class_answers，大屏实时显示「谁的结果对、谁的最快」。你现成的大屏就是数据库课的评测榜。
现场版 · 同一道题全班耗时上墙，最慢与最快差 400 倍——这个差值就是下一节课的引入。
开两个会话同时扣同一件库存，让不可重复读、脏读、死锁在现场发生一次。事务从「背 ACID」变成「我见过」。
现场版 · 两个窗口同时扣最后一件库存，超卖当场发生——再讲 SELECT ... FOR UPDATE。
数据库课的放弃率通常来自三处：开局的抽象、中段的断裂、末端的不真实。
从「只读副本上跑查询」开始，以「答辩你的表为什么这么设计」结束。
一张 EXPLAIN 速读卡、一间慢查询急诊室、一张期末答辩评分表——都能直接印了发。
| type | 什么时候出现 | 它在干什么 | 课堂上的一句话 |
|---|---|---|---|
| const | 主键 / 唯一键等值查询 | 一次定位，只摸一行 | 「拿身份证查人，一翻就中」 |
| ref | 普通索引等值查询 | 按索引扫一小段 | 「按学号点一个班，一页名册」 |
| range | 索引上的范围查询 | 扫一段区间 | 「查 60–80 分，翻一段书页」 |
| index | 覆盖索引扫描 | 顺序扫整棵索引树 | 「比全表快，但仍然在扫」 |
| ALL | 没有可用索引 | 一行一行全摸 | 「报警。第一反应：索引呢？」 |
配套口令：先看 type，再看 rows，最后看 Extra。rows_examined 与返回行数差得越远，优化空间越大——120 万行里只取 37 行，就是下面这间急诊室。
SELECT s.name, e.score FROM students s JOIN enrollments e ON s.id = e.student_id WHERE e.term = '2026-秋' AND e.score < 60 ORDER BY e.score;
三个候选，只有一个建对了地方。选一个，让执行计划宣判。
出题点就两个：最左前缀、等值列在前，范围列在后。选错一次，比讲三遍记得牢。
| 维度 | 权重 | 必须出示的证据 | 评委的当场追问 |
|---|---|---|---|
| ER 与范式取舍 | 30 | ER 图 + 一处「故意反范式」的书面说明 | 「这条冗余，什么时候会反过来咬你？」 |
| 索引论证 | 20 | 每条关键索引的前后耗时对比（EXPLAIN 截图） | 「把查询条件换个顺序，它还灵吗？」 |
| 故障演练 | 20 | 一次真删 + 真恢复的完整记录 | 「你的备份，自己恢复过几次？」 |
| 运维手册 | 20 | 备份策略 / 索引清单 / 慢查询台账 | 「你休假一周，接手的人照着能跑吗？」 |
| 讲述与答辩 | 10 | 10 分钟讲清「你的表为什么这么设计」 | 随堂抽一条 SQL：读出它的执行计划。 |
评分表的潜台词：证据必须在系统里留痕——耗时对比、恢复记录、慢查询台账都来自你现成的大屏与库，不用老师额外造材料。
选定一节课，材料可以一次性配齐——全部咬合你现有的库与大屏。