链式LEFT JOIN与先INNER JOIN再LEFT JOIN的优劣及逻辑原因咨询

你说得没错，在B和C必须INNER JOIN、A和B是LEFT JOIN的业务场景下，这两种写法的输出结果确实一致。除了性能层面的优势外，第二种写法更受青睐的逻辑层面原因主要有这几点：

• 业务逻辑表达更直观
  既然业务上B和C是强关联的INNER JOIN关系，用CTE把这部分逻辑单独抽离出来，就相当于先定义了一个「有效关联的B+C组合」数据集，再和A做LEFT JOIN。这种写法完全贴合业务思考顺序：先拿到符合条件的B+C关联数据，再去关联A，比第一种连续LEFT JOIN的写法更清晰，其他开发者看代码时能立刻明白B和C是绑定的整体，而非各自和A关联的独立表。

• 降低逻辑出错的概率
  第一种写法里，C是直接LEFT JOIN到B上，后续维护时如果有人不小心写错关联条件（比如误写成A.c_id = C.c_id），就会偏离原本的业务逻辑。而第二种写法把B和C的关联逻辑封装在CTE里，相当于固定了这部分关联规则，后续修改或扩展时不容易误改，也不会出现关联条件混乱的情况。

• 代码模块化与复用性
  把B和C的INNER JOIN封装成CTE后，这个逻辑实体可以随时复用——如果后续查询需要多次用到这个「B+C关联数据集」，直接调用CTE即可，不用重复写INNER JOIN的逻辑。就算只使用一次，这种模块化的写法也让整个查询结构更清晰，分块明确，可读性和可维护性更强。

两种写法的代码对比 #

第一种写法：

SELECT *
FROM A
LEFT JOIN B ON A.b_id = B.b_id
LEFT JOIN C ON B.c_id = C.c_id

第二种写法：

WITH cte AS
(
   SELECT *
   FROM B 
   INNER JOIN C ON B.c_id = C.c_id
)
SELECT *
FROM A 
LEFT JOIN cte ON A.b_id = cte.b_id

注：上述代码中使用SELECT *仅为简化表述，实际使用时需避免重复字段（如B和C都有的c_id）。

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