left join 比 inner join 慢主因是语义要求保留左表全部记录，迫使数据库扫描更多行且无法下推右表 where 条件；修复方法包括调整条件位置或用子查询提前过滤右表。
为什么 LEFT JOIN 比 INNER JOIN 还慢？
不是 JOIN 类型本身慢，而是数据库被迫扫描更多行来满足“保留左表全部记录”的语义。LEFT JOIN 会阻止优化器下推 WHERE 条件到右表，导致右表全量关联后再过滤。
- 常见错误现象：
EXPLAIN显示右表type=ALL（全表扫描），即使右表有索引 - 关键修复点：把原本写在
ON后面的右表过滤条件，挪到WHERE子句——但注意，这会把 LEFT JOIN 实际变成 INNER JOIN 效果 - 真正想保留左表又提速？改用子查询提前过滤右表：
SELECT l.*, r.filtered_col FROM left_table l LEFT JOIN ( SELECT id, filtered_col FROM right_table WHERE status = 'active' ) r ON l.r_id = r.id
ON 条件里写 WHERE 会出什么问题？
ON 是关联逻辑，WHERE 是最终结果过滤，混用直接改变语义。尤其在 LEFT/RIGHT JOIN 中，错放条件会让“本该保留的空行”被意外剔除。
- 典型错误：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id AND u.is_deleted = 0
—— 这里u.is_deleted = 0在ON里，会导致u为 NULL 的订单仍被保留，但u.is_deleted字段永远不参与过滤 - 如果目标是“只关联未删除用户”，且仍要保留无用户订单，就该保持原样；如果目标是“只看未删除用户的订单”，那就该把条件移到
WHERE u.is_deleted = 0，并接受它等效于 INNER JOIN - MySQL 5.7+ 和 PostgreSQL 对此行为一致，但 SQLite 可能表现不同——别依赖“好像没报错”
三张表 JOIN 时，顺序和括号真有影响吗？
有，而且影响执行计划。SQL 标准不规定 JOIN 执行顺序，但实际引擎会按从左到右结合，且括号强制优先级。小表驱动大表的前提，可能因顺序错乱彻底失效。
- 避免写成：
A JOIN B JOIN C—— 优化器可能先算B JOIN C（两者都大），再连A - 显式控制顺序：
(A JOIN B ON A.b_id = B.id) JOIN C ON B.c_id = C.id
，确保先走A→B（假设A小） - 更稳的做法：用
STRAIGHT_JOIN（MySQL）或/*+ leading(...) */（PostgreSQL / Oracle hint），但仅当EXPLAIN确认默认计划错误时才用 - 注意：
STRAIGHT_JOIN会禁用部分优化，上线前必须压测
什么时候该放弃 JOIN，改用应用层拼接？
当关联字段无有效索引、结果集稀疏（比如 1:1000）、或跨库/分片时，JOIN 不仅慢，还容易拖垮连接池和内存。
- 典型场景：查 100 个订单，要带每个订单的 3 个最新物流节点（物流表亿级，无订单ID联合索引）
- 实操建议：
① 先查订单：SELECT id, user_id FROM orders WHERE ... LIMIT 100
② 提取所有id数组，一次查物流：SELECT * FROM logistics WHERE order_id IN (1,2,3,...) ORDER BY created_at DESC
③ 应用代码按order_id分组拼接 - 优势：物流表可走
order_id索引，避免嵌套循环扫描；失败可重试单条；方便加缓存 - 坑：注意
IN参数数量限制（MySQL 默认 1000，可通过max_allowed_packet调，但别盲目调大）
关联逻辑越复杂，数据库越难选对执行路径。宁可多跑一次 EXPLAIN，也别信“看起来差不多”的写法。
