SQL查询中LEFT JOIN与INNER JOIN性能差异在哪_通过执行计划分析查询成本-SQL-PHP中文网

inner join通常比left join快，因其支持提前剪枝，无需处理null填充、右表全扫描及保守执行计划等left join隐性开销。

sql查询中left join与inner join性能差异在哪_通过执行计划分析查询成本

INNER JOIN 通常比 LEFT JOIN 快，但原因不在“类型本身”

快不是因为 INNER JOIN 语法更轻量，而是它天然支持“提前剪枝”：数据库在连接过程中一旦发现右表无匹配，整行直接丢弃，不参与后续填充、NULL 处理或结果集构建。而 LEFT JOIN 必须先确保左表每行都进入结果，再为每行尝试查找右表匹配项——哪怕 90% 的左表行在右表都找不到对应，也得走完这个流程。

真正拉大性能差距的往往是这些隐性开销：

LEFT JOIN 需要额外分配内存存储 NULL 填充字段，尤其当右表宽（列多）时，结果集体积明显膨胀
若右表连接字段没索引，LEFT JOIN 可能触发对右表的多次全扫描（每条左表记录都扫一遍），而 INNER JOIN 在优化器判断无匹配后可快速跳过
某些数据库（如 MySQL 5.7）对 LEFT JOIN 的执行计划生成更保守，容易错过基于统计信息的最优路径

ON 条件里写函数会让 LEFT JOIN 性能雪崩

比如把 ON a.id = UPPER(b.ref_id) 这种写法用在 LEFT JOIN 中，会导致右表 b 完全无法使用 ref_id 上的索引——因为函数操作使索引失效。此时数据库只能对右表逐行计算 UPPER() 再比对，数据量稍大就卡住。

正确做法是确保连接字段两侧都保持原始形态：

如果 b.ref_id 存的是小写，就统一存小写，别在 ON 里转大写
实在需要大小写不敏感匹配，改用带校对规则的列（如 COLLATE utf8mb4_0900_as_cs）或建函数索引（MySQL 8.0+ 支持 CREATE INDEX idx_ref_upper ON b ((UPPER(ref_id)))）
INNER JOIN 同样受此影响，但因行数少，恶化程度常被掩盖

WHERE 条件放错位置，LEFT JOIN 就白写了

这是最隐蔽也最致命的性能陷阱：LEFT JOIN 后跟 WHERE b.status = 'paid'，表面看是想筛已支付订单，实际效果是把所有 b.status 为 NULL 的行（即左表无匹配的行）全过滤掉——结果和 INNER JOIN 完全一致，还多花了 LEFT JOIN 的初始化成本。

该写在哪？记住口诀：“连什么”写 ON，“要不要这行”写 WHERE：

只关联已支付订单 → 放 ON：LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid'
查所有用户，但只显示已支付订单的金额 → 仍放 ON，否则 WHERE 一加，没订单的用户就消失了
真要全局过滤（比如排除测试用户），才用 WHERE a.is_test = 0，且必须作用于左表字段

LEFT JOIN 行数等于左表行数，但结果集未必更“重”

很多人以为 LEFT JOIN 因返回更多行，一定更慢。其实不然：如果右表匹配率高（比如 95% 行都能连上），且连接字段有高效索引，LEFT JOIN 和 INNER JOIN 的执行时间可能相差无几。反倒是 INNER JOIN 在高倾斜数据下（如左表 10 万行，仅 100 行能连上），因优化器误判选择嵌套循环而非哈希连接，反而更慢。

关键看三点：