OUTER JOIN导致索引失效的主因是保留表全量扫描、ON中可空列破坏选择性、哈希溢出至tempdb及视图抑制索引下推；应提前过滤、避免ON中函数、更新统计信息、用TVF替代视图。
OUTER JOIN强制保留表全量扫描
因为LEFT JOIN或RIGHT JOIN必须保证保留表（左表或右表）的所有行都出现在结果中，优化器无法像INNER JOIN那样自由选择驱动表或提前过滤。即使你在WHERE里写了针对保留表的条件，只要它出现在JOIN之后，SQL Server就可能先执行全表扫描再过滤——索引自然失效。
常见错误现象：SELECT * FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 'active'，这个WHERE看似能走users.status索引，但实际执行计划里users常被当作保留表全扫一遍。
- 真正起效的写法是把过滤提前：先用CTE或子查询筛出
users子集，再LEFT JOIN - 或者改用INNER JOIN + UNION补NULL（当业务允许时）
- MySQL 8.0+支持
STRAIGHT_JOIN提示，但对OUTER JOIN无效，别白试
ON条件里的NULL值破坏索引选择性
OUTER JOIN的ON子句一旦涉及可空列（比如orders.user_id允许NULL），数据库就很难依赖该列上的索引做高效查找。B+树索引不存储NULL值，而外连接又必须处理“没匹配上”的情况，导致优化器倾向放弃索引、退化为哈希或嵌套循环中的全扫描。
典型场景：给orders.user_id建了索引，但LEFT JOIN orders ON users.id = orders.user_id仍出现Index Scan而非Index Seek。
- 检查执行计划里
Estimated Number of Rows是否远大于实际匹配数——这是索引未被有效利用的信号 - 把
user_id IS NOT NULL显式加进ON条件，有时能帮优化器重估选择性 - 避免在ON里用函数或表达式，比如
COALESCE(orders.user_id, 0)，这直接让索引失效
执行计划里出现Worktable或Spill to TempDB
当LEFT JOIN的结果集太大、内存不够存哈希表，SQL Server会把中间结果写入tempdb，形成Worktable。这时你看到执行计划里有Sort、Hash Match (Outer Join)带红色警告图标，基本可以断定索引没起作用——因为哈希构建阶段根本没走索引查找，而是靠扫描喂数据。
容易被忽略的细节：即使orders表有user_id索引，如果统计信息过期，优化器可能误判其选择性，强行选错算法。
- 定期更新统计信息：
UPDATE STATISTICS orders WITH FULLSCAN - 用
DBCC SHOW_STATISTICS('orders', 'idx_orders_user_id')确认密度向量是否合理 - 临时表替代视图：把LEFT JOIN拆成
SELECT ... INTO #tmp FROM users WHERE ...再JOIN，绕过视图层的优化限制
视图定义本身抑制索引下推
SQL Server对视图的内联展开（view expansion）有严格规则。如果视图里含OUTER JOIN，且外部查询又带聚合、TOP、DISTINCT或非SARGable WHERE条件，优化器大概率放弃展开，转而物化整个视图结果——此时基表索引完全不可见。
举个例子：CREATE VIEW v_user_orders AS SELECT u.*, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id，然后SELECT TOP 10 * FROM v_user_orders WHERE u.status = 'active'，u.status索引几乎必丢。
- 用
WITH SCHEMABINDING创建视图，能提升内联可能性，但要求所有基表必须有架构绑定 - 更可靠的做法：别用视图封装OUTER JOIN逻辑，改用内联TVF（表值函数），传参过滤可下推
- SQL Server 2022的
APPLY+LATERAL语义更可控，但需确认兼容级别≥160
外连接不是不能用，而是它天然携带“保留全部”的语义包袱，任何想靠索引跳过不必要行的操作，都得先说服优化器：这些行真的可以跳。实际调优时，宁可多一步中间表，也别信视图里一个LEFT JOIN能自动变聪明。
