SQL Server：JOIN中使用子查询的可读性与执行效率问题

这是个很实用的问题，咱们从可读性和执行性能两个核心维度来聊清楚：

一、可读性对比 #

先把你提到的示例SQL 2补全成完整的形式，方便对比：

SELECT s.Id, s.TransactionDate, s.TransactionNo, s.CustomerId, s.SubTotal, sd.ItemId, sd.UnitPrice, sd.GrossAmount
FROM (
    -- 子查询仅保留需要的列
    SELECT Id, TransactionDate, TransactionNo, CustomerId, SubTotal 
    FROM tblTransactions
) s
LEFT OUTER JOIN (
    -- 子查询仅保留需要的列
    SELECT TransactionId, ItemId, UnitPrice, GrossAmount 
    FROM tblTransactionDetails
) sd ON sd.TransactionId = s.Id

• 当原表包含大量冗余字段（比如几十上百列）时，用子查询先筛选出当前查询需要的列，能让阅读者一眼聚焦到核心字段上，尤其是在嵌套多层、逻辑复杂的查询里，这种方式的可读性会明显更高，避免在冗长的SELECT列表里反复找关联字段和业务字段。
• 但如果原表列数不多，或者查询逻辑非常简单，直接写JOIN的方式（示例1）会更简洁，少了一层嵌套结构，反而更直观。

二、性能对比 #

这个得结合数据库的查询优化能力来看：

• 现代主流数据库（MySQL、SQL Server、PostgreSQL等）：它们的查询优化器会自动做等价逻辑转换，不管你是直接JOIN整张表再选列，还是先用子查询筛选列再JOIN，最终生成的执行计划几乎是完全一致的，不会有性能差异。优化器会自动识别出只需要读取哪些列，不会因为子查询的存在多做无用功。
• 特殊情况：如果你的子查询里除了筛选列，还加了WHERE条件过滤掉大量无关行，那确实能减少JOIN阶段的数据量，带来性能提升，但这是筛选行的功劳，不是单纯筛选列的结果。
• 老旧数据库：如果用的是优化能力较弱的老旧数据库，先筛选列的子查询可能会让数据库少读取一些不必要的列数据，理论上有微小的性能优势，但这种场景现在已经非常少见了。

总结 #

• 可读性：根据表的列数量和查询复杂度灵活选择，列多、逻辑复杂时优先用子查询筛选列；简单场景直接JOIN更清爽。
• 性能：现代数据库下无需纠结，两者几乎无差异；老旧数据库可能有微小优势，但不用过度关注。

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