商品和明细也到了：三表链与笛卡尔积事故

场景老板要看「每笔订单里都有什么商品」。明细表 order_items 两头各揣一个外键：order_id 指向订单，product_id 指向商品--它就是把三张表串起来的桥。

报表要的列分布在不同表里：单号在 orders、用户名在 users、商品名在 products、数量单价在 order_items。连接链按业务关系走：orders → order_items（一笔订单含多件商品）→ products（商品详情）。四表连起来，每行就是「某笔订单里的某件商品」。

select o.id        as 单号,
       u.name       as 用户,
       p.name       as 商品,
       i.qty        as 数量,
       i.unit_price as 单价
from orders o
join order_items i on i.order_id = o.id
join products   p on p.id = i.product_id
join users      u on u.id = o.user_id
limit 5;

易错连接顺序按链条写、JOIN 一行一个，别把四张表挤在 FROM 里用逗号连接--老式逗号语法没有 ON，漏条件就是笛卡尔积且不报错。

场景你连了 order_items 统计订单 GMV，总金额凭空翻了倍--数据没坏，是行数被放大了。

orders 和 order_items 是一对多：一笔订单平均挂 2-3 件商品，连接后同一笔订单变成 2-3 行，sum(o.total_amount) 就把它重复累加了。判断连接后该有多少行：沿连接链找「多」的那一端，结果行数 = 多端行数（前提都匹配上）。

select count(*) from orders;        -- 5 万
select count(*) from order_items;    -- ≈12 万
select count(*)
from orders o
join order_items i on i.order_id = o.id;   -- ≈12 万，等于明细行数

易错「连了明细表之后聚合数字变大」首先怀疑一对多放大。修法：先按 order_id 聚合明细、再连接回主表（D14 周测专门考）。

场景漏写一个 ON，笔记本风扇狂转--你正在计算两表所有行的组合。

没有 ON 的 JOIN 退化为 CROSS JOIN：结果行数 = 两表行数之积。orders 5 万行 × order_items 12 万行 = 60 亿行，数据库真的会一行行算出来。这是新手把库跑挂的第一名原因。

-- 惰性：LIMIT 几行就停，可以看到组合的样子
select o.id, i.id
from orders o cross join order_items i
limit 5;

-- 危险：count(*) 要把 60 亿行数完才返回，别在脑子里跑
-- select count(*) from orders cross join order_items;

易错EXPLAIN 里看到两侧都没有过滤条件、估行数 = 两表行数之积，就是在算笛卡尔积--赶紧 Ctrl+C。

场景PG 允许 using (...) 简写，natural join 甚至自动按同名列连接--看起来更省事。

using (列) 要求两边的连接列同名；本库里 orders.user_id 对 users.id，名字不同，USING 根本写不了。natural join 更激进：把所有同名列全当连接条件。省几个字的代价是赌表结构永远不变--哪天加了一个同名列，natural join 的连接条件悄悄变了，结果变了，不报任何错。

-- 本库写不了 USING（连接列不同名），只能显式 ON：
select o.id, u.city
from orders o
join users u on o.user_id = u.id;

易错生产代码里见到 natural join 就重构；显式 ON 多打几个字，换来的是改动安全。