JOIN本质是按条件配对而非拼表，先笛卡尔积再过滤；INNER JOIN仅保留双匹配行，LEFT JOIN保留左表全部并补NULL；ON在连接时过滤，WHERE在连接后全局过滤。
JOIN 为什么不是“把表拼在一起”而是“按条件配对”
很多人初学 JOIN 时默认它像 Excel 合并工作表一样“横向堆叠”，结果查出重复、丢失或爆炸式行数。本质是：JOIN 是基于关联字段做笛卡尔积后再过滤，不是物理拼接。比如 users 表 100 行、orders 表 500 行，没 ON 条件的 CROSS JOIN 会先生成 5 万行，再筛——这正是性能崩掉的起点。
实操建议：
- 写
JOIN前必须明确「哪一列是双方共有的逻辑主键/外键」，比如users.id = orders.user_id -
ON子句不能省略（除非真要CROSS JOIN），且条件字段最好都有索引 - 用
EXPLAIN看执行计划，确认是否走了索引；若出现Using join buffer，大概率关联字段缺索引
INNER JOIN 和 LEFT JOIN 的行为差异在哪
INNER JOIN 只保留两边都匹配的行；LEFT JOIN 以左表为基准，右表无匹配则补 NULL。这不是“左表优先”，而是语义上「保留左表全部记录」——哪怕右表根本没这条数据。
常见错误现象：
- 本想查所有用户及其订单，却写了
INNER JOIN，结果没下单的用户直接消失 - 在
WHERE里对右表字段加非空限制（如WHERE orders.status = 'paid'），把LEFT JOIN变相转成INNER JOIN，因为NULL不满足等值判断 - 多层
LEFT JOIN后聚合（如COUNT()），没加COALESCE或条件判断，导致统计失真
三张及以上表连接时，顺序和括号影响结果吗
SQL 标准中 JOIN 是左结合的，即 A JOIN B JOIN C 等价于 (A JOIN B) JOIN C，但实际结果是否一致，取决于连接条件是否传递、是否有中间表充当“桥梁”。
使用场景与风险：
- 如果
A和C没直接关联字段，必须通过B中转（如A.user_id = B.id且B.customer_id = C.id），顺序不能乱 - 当某张中间表存在一对多关系（如一个用户有多个地址），前置连接它会导致后续表数据被“撑开”，行数指数增长
- MySQL 8.0+ 支持
LATERAL，可在JOIN中引用前序表字段做子查询，适合动态关联场景，但兼容性有限
WHERE 和 ON 对 LEFT JOIN 的过滤效果完全不同
这是最常踩的坑。ON 是连接时的匹配条件，决定哪些右表行能挂到左表记录上；WHERE 是连接完成后的全局过滤，会剔除整行——包括左表原本该保留的记录。
举个例子：查用户 + 最新订单（假设用 order_date 排序取第一条）
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.id = ( SELECT id FROM orders o2 WHERE o2.user_id = u.id ORDER BY order_date DESC LIMIT 1 )
注意：AND o.id = (...) 必须写在 ON 里。如果挪到 WHERE，就会把没订单的用户也过滤掉。
性能提示：
- 复杂子查询放
ON可能无法走索引，考虑先用窗口函数或临时表预计算最新订单 ID - MySQL 5.7 对
ON中的子查询支持较弱，建议升级或改用JOIN+ROW_NUMBER()（8.0+）
真正难的不是语法，是厘清「我要的是匹配逻辑，还是最终筛选逻辑」——这两个动作发生在不同阶段，混用就等于让数据库做两遍事。
