每个join后必须紧随on子句，否则mysql 8.0+报错，旧版或orm可能转为cross join导致行数相乘；on中应包含右表过滤条件以保left join语义；一对多关联需先聚合再join避免逻辑放大；用explain和窗口函数及时识别结果集膨胀。
每个JOIN后面必须紧跟着ON子句
不写ON，数据库不会猜你要连哪列——MySQL 8.0+ 直接报ERROR 1064，旧版或某些ORM可能静默转成CROSS JOIN，结果就是行数相乘。比如orders有1万行、customers有5千行，漏掉ON就生成5千万行。
- 错误写法：
SELECT * FROM orders LEFT JOIN customers; - 正确写法：
SELECT * FROM orders LEFT JOIN customers ON orders.customer_id = customers.id; -
USING (customer_id)可以替代ON，但要求两表字段名完全一致且类型兼容，不是“省条件”的捷径 - 子查询当表用时同样要
ON，比如LEFT JOIN (SELECT order_id, SUM(amount) FROM payments GROUP BY order_id) p ON o.id = p.order_id，不能写ON 1=1
LEFT JOIN的过滤条件必须写在ON里，不能放WHERE
WHERE是在连接完成之后才执行，而ON控制的是“哪些右表行参与连接”。把右表过滤条件（如状态、类型）放在WHERE里，会先全量匹配再砍掉NULL行，等效于INNER JOIN，还白跑一遍膨胀计算。
- 危险写法：
LEFT JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active'→ 所有没匹配到活跃客户的订单都被丢掉 - 安全写法：
LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active'→ 只拉活跃客户，左表订单全保留 - 如果业务要求“查所有订单，只显示VIP客户信息”，
WHERE里绝不能出现c.vip_level这类右表字段
一对多表同时JOIN时，先聚合再关联
主表1行，明细表A有3行、明细表B有5行，直接LEFT JOIN A再LEFT JOIN B，结果是1×3×5=15行——这不是语法错，是逻辑放大。数据库只能把两边明细互相组合，因为A和B之间没有业务关联。
- 低效写法：
SELECT m.id, a.qty, b.price FROM main m LEFT JOIN detail_a a ON m.id = a.main_id LEFT JOIN detail_b b ON m.id = b.main_id - 推荐写法：把明细侧先收拢粒度，例如
(SELECT main_id, SUM(qty) AS total_qty FROM detail_a GROUP BY main_id)和(SELECT main_id, AVG(price) AS avg_price FROM detail_b GROUP BY main_id)，再分别JOIN主表 - 若需最新一条明细，用
ROW_NUMBER() OVER (PARTITION BY main_id ORDER BY updated_at DESC)筛，别让引擎自己枚举所有组合
用EXPLAIN和窗口函数快速验证是否已膨胀
别等全量查询跑崩了才发现问题。加个COUNT(*) OVER (PARTITION BY ...)就能看出哪张表在失控拉数据；EXPLAIN里的rows值如果远超实际表行数，基本就是连接条件失效或类型不匹配。
- 快速诊断示例：
SELECT u.id, COUNT(*) OVER (PARTITION BY u.id) AS order_cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id ORDER BY order_cnt DESC LIMIT 5，一眼揪出order_cnt异常高的用户 -
EXPLAIN中看到某表type为ALL或rows比实际大几个数量级，优先检查：ON字段类型是否一致（如BIGINTvsVARCHAR）、索引是否存在、有没有隐式转换 -
LIMIT 100只用于秒级确认问题规模——如果它都卡住，说明中间结果集早已失控，别指望靠LIMIT救性能
真正麻烦的从来不是“没写ON”，而是写了却因字段重复、NULL、类型不一致或逻辑断链，让数据库不得不暴力匹配。每一步JOIN后的中间结果，都该用LIMIT 5或窗口计数看一眼行数是否合理。
