在业务系统里，多表 JOIN 是日常查询的基础操作，但不少人在写 SQL 时容易把结果集算错或者把数据库拖慢。根本原因在于动手写 JOIN 之前，没有把表与表之间的业务关系梳理清楚。先建立正确的数据模型，再选择连接方式，才能写出稳定可靠的查询。
先搞清楚实体之间的关系
在落笔写 SQL 前，建议先在纸上或脑图中明确以下三点：
- 哪些表是核心实体表，比如用户表、订单表
- 实体之间是一对一、一对多还是多对多
- 连接字段是否具备唯一性约束
如果订单表和用户表是一对多，那么以用户为主表左接订单，一个用户就会展开成多行；若误用内连接且订单有重复，就可能放大统计结果。
一对多的常见误用
假设我们要计算每个用户的下单总数，错误写法可能直接 COUNT 了展开后的行：
-- 错误示例：一对多直接 JOIN 后 COUNT 会重复计算用户 SELECT u.id, COUNT(u.id) AS cnt FROM user u LEFT JOIN order o ON u.id = o.user_id GROUP BY u.id;
上面语句中，如果一个用户有 3 个订单，cnt 会等于 3，这在某些统计里是对的，但在算用户数时就错了。应先聚合子表再 JOIN：
-- 正确思路：先聚合订单，再关联用户 SELECT u.id, IFNULL(o.order_cnt, 0) AS order_cnt FROM user u LEFT JOIN ( SELECT user_id, COUNT(*) AS order_cnt FROM order GROUP BY user_id ) o ON u.id = o.user_id;
多对多必须引入中间表
学生和课程是典型的多对多关系。直接把 student 和 course 做 JOIN 而没有选课记录表，在模型上就不成立。正确建模应引入 enrol 中间表：
-- 查询选修了某课程的学生 SELECT s.name, c.title FROM student s JOIN enrol e ON s.id = e.student_id JOIN course c ON e.course_id = c.id WHERE c.title = '数据库基础';
用连接类型表达业务语义
内连接表示两边都要有匹配，左连接保留左表全部记录。建模时要想清楚：缺失关联数据是业务异常，还是正常情况。比如报表要列出所有用户，哪怕没下单，也要用左连接而不是内连接。
| 关系类型 | 推荐连接 | 说明 |
|---|---|---|
| 一对一 | 内连接 | 两边唯一，结果行数不变 |
| 一对多 | 左连接或内连接 | 看是否要保留主表全部 |
| 多对多 | 通过中间表双 JOIN | 不能直接两表相联 |
动手前的检查清单
写 JOIN 之前，建议按下面顺序自检：
- 画出实体关系，标出基数
- 确认连接字段有索引
- 预想结果集行数是否合理
- 聚合类指标是否先在子表算好
只要建模阶段把关系理顺，SQL 里的 JOIN 只是顺手完成的表达，而不是反复试错的地雷区。