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

easycode · Agent Skill

第一册第 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 随便跑，这是安全的练习场。