sql教程

很多人第一次写 SQL，是在一个紧急需求里——产品经理要一份“上周下单超过3次但没付款的用户名单”，你打开数据库客户端，面对几十张表，脑子里只剩一个念头：JOIN 到底怎么写才不会把数据翻倍。

SQL 不是“编程语言”里最难的那种，但它有个特点：语法看起来像英语，写错了却不一定报错，只是结果不对。这比报错更可怕。我见过一个运营同学，用 LEFT JOIN 统计订单和退款，结果把 200 单算成了 340 单，因为退款表里一个订单对应多条记录。她盯着屏幕看了半小时，最后是财务发现金额对不上才回头查。

先记住一件事：SQL 查询的逻辑执行顺序，和你写的顺序不一样。你写的是 SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ...，但数据库实际先处理 FROM 和 JOIN，确定数据源；然后 WHERE 过滤行；接着 GROUP BY 分组；再 HAVING 过滤组；之后才轮到 SELECT 计算字段；最后 ORDER BY 排序。这个顺序解释了为什么 WHERE 里不能直接用 SELECT 里的别名——那时候别名还没被计算出来。

拿一个具体例子。假设有两张表：users（id, name, city）和 orders（id, user_id, amount, created_at）。你要查“北京用户中，2024 年 1 月之后下过单的人，以及他们的订单总数”。

SELECT u.name, COUNT(o.id) AS order_count FROM users u JOIN orders o ON u.id = o.user_id WHERE u.city = '北京' AND o.created_at >= '2024-02-01' GROUP BY u.id, u.name ORDER BY order_count DESC;

这里有几个容易踩的坑。第一，GROUP BY 后面写 u.id 就够了，因为 id 是主键，但很多数据库要求把 SELECT 里非聚合的字段都列出来，所以 u.name 也得写上。第二，COUNT(o.id) 和 COUNT(*) 结果可能不同——如果 JOIN 之后某些行 o.id 为 NULL，COUNT(*) 会算进去，COUNT(o.id) 不会。第三，WHERE 里的条件是在 JOIN 之后过滤的，如果你想要“所有北京用户，包括没下单的”，得把 o.created_at 的条件挪到 ON 子句里，并且用 LEFT JOIN。

再说一个日常操作：去重。很多人用 DISTINCT，但 DISTINCT 作用于整行，不是单个字段。比如 SELECT DISTINCT city FROM users 没问题，但 SELECT DISTINCT city, name FROM users 会把“北京-张三”和“北京-李四”都保留。如果你只想看有哪些城市，别把 name 放进去。

窗口函数是另一个分水岭。没有窗口函数的时候，要算“每个城市订单金额排名前 3 的用户”，得写子查询或者变量，又长又容易错。有了 ROW_NUMBER() OVER (PARTITION BY city ORDER BY amount DESC)，直接套一层外层查询过滤 rank <= 3 就行。我自己的经验是：一旦发现查询里出现“每组前 N 个”或者“累计到当前行的总和”，优先想窗口函数，别硬写 GROUP BY。

索引的事也顺带提一句。WHERE 里对字段用函数，比如 WHERE DATE(created_at) = '2024-02-01'，索引基本就废了。改成 WHERE created_at >= '2024-02-01' AND created_at < '2024-02-02'，效果一样，但能走索引。这个细节在数据量上百万之后，查询时间能从几秒变成几十毫秒。

写 SQL 最怕的不是复杂，是“看起来对”。跑出结果之后，拿几条明细手动核对一下，或者用 COUNT(*) 和 COUNT(DISTINCT id) 对比一下，往往能提前发现 JOIN 膨胀的问题。数据库不会骗你，但它也不会主动告诉你哪里错了。