MySQL JOIN结果由连接类型和ON条件决定，WHERE中对右表筛选会使LEFT JOIN等效于INNER JOIN；应将右表条件移至ON子句，并确保索引、类型一致及驱动表合理。
JOIN 语法写错顺序，查不到数据很常见
MySQL 的 JOIN 不是“先写哪张表就以它为主”，而是由连接类型和 ON 条件共同决定结果集。很多人误以为 LEFT JOIN 左边的表一定全量返回，但一旦在 WHERE 子句里对右表字段加了非空条件（比如 WHERE t2.status = 'active'），就会把左表中对应右表为 NULL 的行过滤掉，实际效果等同于 INNER JOIN。
正确做法是：把右表的筛选条件尽量放在 ON 子句里，而不是 WHERE：
SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active';
-
ON中的o.status = 'active'只影响关联逻辑，不筛左表 -
WHERE o.status = 'active'会剔除所有o为NULL的用户行 - 多表关联时，
ON条件只作用于当前JOIN的两张表，不能跨跳引用更早的表（除非用子查询或括号明确分组）
INNER JOIN 和 LEFT JOIN 性能差异其实没那么大
很多人觉得 LEFT JOIN 比 INNER JOIN 慢，其实是误解。真实瓶颈往往出在缺失索引、连接字段类型不一致，或者驱动表选择不当。MySQL 优化器会根据统计信息自动选驱动表，但如果你强制用 STRAIGHT_JOIN 或者表顺序写反了（比如小表放右边又没索引），性能反而暴跌。
检查要点：
- 确认
ON字段都有索引，且类型完全一致（VARCHAR(50)和VARCHAR(100)也可能导致索引失效） - 用
EXPLAIN看type是否为ref或eq_ref，避免ALL全表扫描 - 如果左表数据量远大于右表，又必须用
LEFT JOIN，考虑先用WHERE对左表做前置过滤
三张及以上表 JOIN 容易漏掉中间依赖关系
比如查「用户 → 订单 → 订单商品」，有人直接写：
SELECT u.name, o.order_id, i.item_name FROM users u JOIN orders o ON u.id = o.user_id JOIN items i ON o.id = i.order_id;
看起来没问题，但如果 items 表里有脏数据（比如 order_id 指向一个已删除的订单），这条语句仍会返回结果 —— 因为 JOIN 只校验字段值相等，不校验业务有效性。更隐蔽的问题是：如果 orders 和 items 之间还该经过一个中间状态表（如 order_status），漏掉它可能导致数据口径偏差。
- 业务上强依赖的链路，建议显式补全每层关系，哪怕只是
JOIN status s ON o.status_id = s.id WHERE s.code = 'paid' - 用
USING替代重复的ON（如JOIN orders USING (user_id)）可读性更好，但要求字段名完全一致 - 复杂多表场景下，优先考虑把部分逻辑拆成子查询或临时表，比堆砌 5 个
JOIN更易维护和调试
GROUP BY 后 SELECT 字段受限，别硬塞非聚合字段
MySQL 5.7+ 默认开启 sql_mode=ONLY_FULL_GROUP_BY，这意味着 SELECT 列表里除了聚合函数（COUNT()、MAX() 等），其他字段必须出现在 GROUP BY 中。很多人为了绕过报错，直接关掉这个模式，结果查出来的非分组字段值是随机的 —— 尤其在多表 JOIN 后，根本没法保证一致性。
稳妥做法：
- 确保
GROUP BY包含所有非聚合字段，例如GROUP BY u.id, u.name, o.status - 如果只想取每个用户的最新订单，别用
GROUP BY u.id+SELECT u.name, MAX(o.created_at)，这无法拿到对应那条订单的order_id；改用窗口函数（MySQL 8.0+）或关联子查询 - 实在要兼容旧模式，至少加注释说明该字段值不可靠，避免下游误用
多表 JOIN 的边界感很容易模糊，特别是当业务字段语义重叠（比如多个表都有 status）、或者关联路径存在一对多时，查出来一行还是多行、NULL 出现在哪一列，都得对着 EXPLAIN 和少量样本数据手动验证一遍。别信直觉，信 SELECT * 加 LIMIT 5 的实测结果。
