高效不靠join语法本身，而靠on条件写法、索引覆盖、驱动表选择这三点；inner join语义上只保留匹配行，优化器更易选优驱动表，left join则强制保留左表全量，若右表索引缺失或where误用会退化为全表扫描并丢失null行。
直接说结论：高效不靠JOIN语法本身，而靠ON条件写法、索引覆盖、驱动表选择这三点。没做这三件事，写得再“标准”的JOIN也容易拖垮查询。
INNER JOIN 和 LEFT JOIN 的语义差异直接影响结果行数
很多人以为换掉JOIN类型只是“多几行NULL”，其实它会改变整个执行逻辑和结果集大小：
-
INNER JOIN只保留两表都匹配的记录，优化器更可能选小表当驱动表，性能通常最好 -
LEFT JOIN强制保留左表全部数据，一旦右表没索引或条件写错，就容易触发全表扫描+临时表 - 常见错误：把本该在
ON里的右表过滤条件（比如status = 'paid'）误塞进WHERE—— 这会让LEFT JOIN实际退化成INNER JOIN，丢失预期中的NULL行
ON 条件必须写在对应 JOIN 后面，不能堆到末尾
MySQL解析时按SQL书写顺序逐个处理JOIN，ON只对紧邻的前一个表生效。写错位置会报Unknown column或生成笛卡尔积：
- 正确写法：
FROM orders o JOIN users u ON o.user_id = u.id JOIN items i ON o.item_id = i.id - 错误写法：
FROM orders o JOIN users u JOIN items i ON o.user_id = u.id AND o.item_id = i.id—— 第二个JOIN没带ON，i表实际和o、u都未关联 - 三张及以上表连接时，每对表之间都要显式写出
ON，哪怕左边字段重复出现（如o.id = i.order_id和o.user_id = u.id都用o开头）
没有索引的 ON 字段会让 JOIN 变成全表扫描
即使只查10行数据，只要ON字段没索引，MySQL就得对右表做嵌套循环遍历，时间复杂度O(n×m)：
- 检查方式：用
EXPLAIN看type列，ALL或index说明没走有效索引；ref或eq_ref才是健康状态 - 复合索引要遵循最左前缀：如果
ON a.id = b.a_id AND b.deleted = 0，索引应建在(a_id, deleted)而非单列a_id -
JOIN字段类型必须严格一致：INT对BIGINT、VARCHAR(50)对VARCHAR(100)都可能导致索引失效
LEFT JOIN 后的 WHERE 条件极易误伤 NULL 行
这是线上最常被忽略的坑——WHERE是在JOIN完成之后才执行的，所有右表字段为NULL的行，都会被等值条件（如u.status = 'active'）直接过滤掉：
- 想保留所有订单，并只关联状态为
active的用户？必须把条件写进ON：LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active' - 如果真需要过滤左表（比如只查
created_at > '2025-01-01'），可以放心放WHERE，它不影响连接逻辑 - 不确定时，先用
SELECT *跑一遍，确认NULL行是否还在结果里，再加WHERE
真正卡住性能的往往不是JOIN本身，而是ON条件没索引、LEFT JOIN被WHERE悄悄阉割、或者三张表连着写却漏了一个ON——这些地方一错，explain出来的rows可能从百级跳到百万级。
