第 8 章 SQL 再进一步：读懂一条真正的查询

第一册第 3 章给了你四个动词，这一章读一条带筋骨的真查询——它长得像我们 Supabase 里会出现的样子：

SELECT certificates.id, users.email
FROM certificates
JOIN users ON users.id = certificates.owner_id
WHERE certificates.status = 'minted'
ORDER BY certificates.created_at DESC
LIMIT 20;

SQL 有个反直觉的秘密：读它不从第一行读，从 FROM 读。顺序是——FROM：从 certificates 表出发；JOIN ... ON：把 users 表按对应关系拼过来（凭证的 owner_id 对上用户的 id——这种"表与表之间的工号"叫外键，第四册讲怎么设计，这册先会读）；WHERE：只留状态是 minted 的行；ORDER BY ... DESC：按创建时间倒序，新的在前；LIMIT 20：只要前二十条；最后才轮到 SELECT：从结果里端出哪几列。整句人话："找出最近铸造成功的二十张凭证，附上主人的邮箱。"

JOIN 的直觉不难：两张 Excel 表按"工号"对齐、拼成一张宽表。为什么当初要拆成两张？因为用户信息只该存一份——用户改邮箱，只改一处，所有凭证自动"知道"。这条不重复原则是数据库设计的地基，第四册展开。

接下来是本章的红线雷达，请刻进反射弧：**见到 UPDATE 或 DELETE 后面没有 WHERE，立刻停下叫人。**没有 WHERE，意思是"整张表全部改掉/删掉"。AI 写的迁移脚本、清理脚本里一旦出现这个形状，无论它解释得多合理，都触发第一册红线卡上那条"直接操作生产数据库"——人是最后一道闸。

最后说说 SQL 在我们生活里藏在哪：Supabase 的 Table Editor 里每次点击背后都是一条 SQL；SQL Editor 能直接跑；第一册第 3 章讲的迁移文件，本体就是一串 SQL 存档——AI 每次"建表"产出的就是它们。从今天起，你能读它的迁移了。至于那些 CREATE POLICY 开头的语句——那是 RLS 的权限规则（谁能看哪些行），也是 SQL；这册认出它是什么就行，第四册第 6 章亲手写。

认脸卡

后缀 .sql；关键词习惯全大写；分号收尾；全家族里英语味最重的一门。

关键领悟

读 SQL 的顺序是 FROM → JOIN → WHERE → SELECT。外加一条铁律：没有 WHERE 的 UPDATE/DELETE，永远先叫人。

试一试

打开 Supabase 的 SQL Editor，让 AI 给我们某两张表写一条只读的 JOIN 查询。先自己逐层翻译，再运行，对照结果验证理解。（只读的 SELECT 随便跑，这是安全的练习场。）