SQL LEFT JOIN表连接顺序对查询结果与性能的影响解析

问题背景 #

完成LEFT JOIN练习题时遇到题目要求：

列出所有分类名称及其对应的产品数量。
题目基于Northwind数据库的两张表实现：

• products表：共77行数据
• categories表：共8行数据

最初思路是将products表作为LEFT JOIN左表（主表），理由是核心统计指标（产品数量）来源于该表，仅需从关联表获取8条分类名称即可。但正确结论是categories表才应当作为主表，以下是两种写法的SQL和原理解释。

两种实现SQL #

写法1：categories作为左表（符合题目要求） #

SELECT C.CategoryID, CategoryName, COUNT(ProductID) [Count]
FROM Categories C LEFT JOIN Products P
    ON C.CategoryID = P.CategoryID
GROUP BY C.CategoryID, CategoryName

写法2：products作为左表（不符合语义要求） #

SELECT P.CategoryID, CategoryName, COUNT(ProductID) [Count]
FROM Products P LEFT JOIN Categories C
    ON P.CategoryID = C.CategoryID
GROUP BY CategoryName, P.CategoryID

问题解答 #

1. 为什么必须选categories作为左表 #

LEFT JOIN的核心语义是保留左表的全部记录，右表匹配不到关联条件的字段全部填充NULL。题目要求“列出所有分类”，意味着哪怕某个分类下没有任何关联产品，也需要出现在结果中，对应产品数量显示为0。
如果以products作为左表，结果中只会出现存在对应产品的分类——没有任何产品的分类因为在products表中没有匹配记录，会直接被排除在结果集外，本质是没有满足题目“列出所有分类”的核心要求，和统计字段来自哪张表没有关系。

2. LEFT JOIN表顺序影响性能的原理 #

和可以随意交换表顺序的内连接不同，LEFT JOIN的表顺序会直接影响执行性能，核心原因是：

• 数据库优化器生成执行计划时，不能随意交换外连接的左右表顺序——交换顺序会直接改变查询语义，导致返回结果错误，因此外连接的重排优化空间非常有限，写SQL时指定的左表，绝大多数场景下就是执行计划里的驱动表。
• 最常见的嵌套循环关联逻辑是：逐行遍历驱动表的记录，到被驱动表中匹配符合关联条件的行。驱动表的行数越少，遍历的轮次就越少，关联查询的整体开销就越低。
  本场景中categories只有8行，作为驱动表时仅需要做8次到products表的匹配查找；如果反过来用77行的products作为驱动表，就需要做77次匹配查找，小数据量下差异不明显，但量级放大后性能差距会非常大。

3. 数据量规模对关联性能的影响 #

表的数据量规模对关联查询性能的影响是直接的：

• 当驱动表数据量远小于被驱动表，且被驱动表的关联字段建有索引时，嵌套循环关联的性能极高——哪怕被驱动表是千万级别的大表，只要驱动表只有几十到上百行，查询依然可以在毫秒级返回结果。
• 如果反过来用大表作为驱动表，哪怕被驱动表很小、关联字段有索引，遍历大表带来的IO、计算开销会随数据量增长线性上升，数据量越大性能下降越明显。
• 如果两张关联表都是大表，数据库可能会选择Hash Join、Sort Merge Join等其他关联策略，这时候表顺序对性能的影响会比嵌套循环场景小，但依然要优先满足查询语义的正确性要求，不能为了性能调换左右表导致结果错误。

内容的提问来源于stack exchange，提问作者Zos