非相关子查询未走索引导致key为null，主因是字段缺失索引、隐式转换、统计信息滞后或优化器误判；应检查类型一致性、更新统计信息或显式物化结果并建索引。
非相关子查询没走索引，不是子查询“不相关”就天然安全——SQL Server 2019 仍可能因执行计划误判、统计信息滞后或隐式转换，让本该走索引的内层查询退化为表扫描。
为什么非相关子查询的执行计划里 key 是 NULL
非相关子查询（如 WHERE id IN (SELECT id FROM ref WHERE status = 'A')）理论上可独立执行一次，但 SQL Server 并不保证它一定走索引。关键看执行计划中该子查询对应 RelOp 节点的 PhysicalOp 和 EstimateRows：
- 若节点显示
PhysicalOp="Table Scan"或Index Scan，且EstimateRows远大于实际匹配行数，说明优化器放弃了索引查找 -
key=NULL出现在 XML 执行计划的IndexScan或Seek属性里，代表未选定有效索引——常见于子查询 WHERE 条件字段缺失索引，或存在隐式转换 - 检查子查询是否含非确定性函数（如
GETDATE()、NEWID()），哪怕只写在注释里，某些 CU 版本也会误标为Uncacheable，强制降级为扫描
IN 子查询里外层字段类型不一致，索引直接失效
即使子查询本身非相关，只要外层 WHERE 使用了 IN，且字段类型与子查询结果列不严格匹配，就会触发隐式转换，导致索引无法用于驱动侧查找：
- 例如外层
orders.user_id INT，子查询返回ref.user_id VARCHAR(32)，SQL Server 会悄悄转成CONVERT(int, ref.user_id)，索引失效 - 验证方法：把子查询单独拎出来执行
SELECT TOP 1 user_id FROM ref WHERE status = 'A'，用sp_help ref确认字段类型；再对比外层字段定义 - 修复不是加
CONVERT，而是统一类型——要么改参数/变量声明，要么在子查询里显式CAST(user_id AS INT)并确保该列有对应索引
统计信息过期或基数估算严重偏差
非相关子查询是否走索引，高度依赖优化器对子查询结果集大小的预估。若统计信息陈旧，EstimateRows 可能是真实值的 10 倍或 1/10，导致它认为“扫全表比走索引快”：
- 运行
DBCC SHOW_STATISTICS('ref', 'IX_ref_status')查看ModificationCount，若远大于表总行数 20%，立刻更新：UPDATE STATISTICS ref IX_ref_status WITH FULLSCAN - 特别注意分区表或大宽表：默认采样率可能不足，
WITH FULLSCAN虽慢但可靠；SQL Server 2019 默认启用自动更新，但仅当修改行数 > 20% + 500 行才触发，冷数据容易漏掉 - 如果子查询带
TOP或OFFSET/FETCH，优化器常低估结果集，可临时加OPTION (RECOMPILE)强制重编译，但别长期依赖
物化中间结果比硬调子查询更可控
当反复验证子查询逻辑正确、索引也建了，但执行计划仍固执地走扫描，最务实的做法不是继续猜优化器意图，而是绕过它：
- 用
SELECT id INTO #ref_filtered FROM ref WHERE status = 'A'显式物化结果，再建索引：CREATE CLUSTERED INDEX IX_tmp_id ON #ref_filtered(id) - 外层改写为
WHERE id IN (SELECT id FROM #ref_filtered)或更优的INNER JOIN #ref_filtered，执行计划彻底扁平，key和type都可预期 - 注意：临时表名必须唯一，避免并发冲突；若子查询结果超百万行，考虑用
CREATE TABLE #ref_filtered (...)+INSERT INTO ... SELECT替代SELECT INTO，便于加约束和索引
真正难缠的不是“为什么没走索引”，而是“为什么明明满足所有条件，优化器还是选错”。SQL Server 2019 的代价模型对嵌套层级、统计分布、内存压力都敏感，与其花半天调参，不如用物化+显式索引把控制权拿回来。
