LEFT JOIN被转为INNER JOIN的触发条件是WHERE子句对右表字段施加非NULL约束（如WHERE b.col = 'x'或b.id IS NOT NULL），此时逻辑等价于交集，优化器自动改用更高效执行路径。

LEFT JOIN被悄悄转成INNER JOIN的触发条件

SQL Server 2019 的查询优化器会在语义允许的前提下，自动将 LEFT JOIN 重写为 INNER JOIN，这不是 bug，而是合法且激进的优化行为。关键在于：**WHERE 子句中对右表字段施加了非 NULL 约束**。

• WHERE b.status = 'active' 或 WHERE b.id IS NOT NULL 这类条件，直接排除了所有右表无匹配（即 b.* 全为 NULL）的行
• 此时逻辑上已等价于只保留两表交集，优化器会跳过 LEFT 语义的“保左”开销，改用更高效的 INNER 执行路径
• 即使你写了 LEFT JOIN，执行计划里实际出现的也是 Hash Match (Inner Join) 或 Nested Loops (Inner Join)

ON 和 WHERE 放错位置导致的隐式转换

这是最常踩的坑：把本该在连接阶段过滤的条件，错误地写进了 WHERE。结果不是“查得不对”，而是“查得慢还等效于 INNER”。

• 错误写法：FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.create_time > '2023-01-01' → 右表字段在 WHERE 中非空约束，强制退化
• 正确写法：FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.create_time > '2023-01-01' → 过滤提前到连接条件，保留 LEFT 语义，且右表只读匹配行
• 验证方法：看执行计划中 Estimated Number of Rows 是否接近左表总行数；若远小于，大概率已被优化为 INNER

如何确认你的LEFT JOIN是否被重写

不能只看 SQL 文本，必须查执行计划和实际行为。

• 打开实际执行计划（Ctrl+M），观察每个 Join 操作符的类型：是 Left Outer Join 还是 Inner Join
• 检查 Properties 面板中的 Logical Operation 和 Physical Operation 字段，二者都应为 Left Outer Join 才算真正生效
• 对比 Actual Number of Rows：若远小于左表行数，且右表有索引但未走 Seek（而是 Scan），说明优化器已按 INNER 处理，但可能因统计信息不准选错了算法
• 禁用该优化（仅调试用）：OPTION (QUERYTRACEON 4199) 不影响，但可加 OPTION (USE HINT('DISABLE_OPTIMIZER_ROWGOAL')) 辅助判断，不过不推荐生产环境使用

为什么优化器敢这么干？它怎么知道安全

SQL Server 依赖列级统计信息 + 约束元数据做语义推断。只要满足以下任一，就认为转换安全：

• 右表连接字段上有 NOT NULL 约束，且 WHERE 条件又进一步限定其值（如 = 'X'）
• 右表在连接条件中参与了唯一键/主键匹配（如 ON a.id = b.order_id，而 b.order_id 是 PK），此时每条左表行最多匹配一条右表行，且 WHERE 排除 NULL 后只剩有效匹配
• 存在外键关系（FOREIGN KEY），优化器能确认右表所有匹配行必然存在，NULL 行不可能出现

真正容易被忽略的是：这种转换虽提升性能，但会掩盖业务逻辑缺陷——比如你以为在查“所有用户及他们的活跃订单”，结果因 WHERE 写错，实际只查了“有活跃订单的用户”，而报表口径已悄然变化。查之前，先确认意图是否真需要 LEFT 语义。