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 语义。
