SQL Server执行计划中“Dependency_”并非真实算子，而是SSMS对关联子查询跨作用域引用的渲染提示；它不参与实际执行，仅标识编译期推导出的依赖关系，真正影响性能的是该依赖是否触发嵌套循环、索引失效或重复计算。
SQL Server 为什么在执行计划里显示 “Dependency_” 节点
执行计划中出现 Dependency_ 并不是 SQL Server 的标准算子名称，而是 SQL Server Management Studio（SSMS）或某些第三方工具在图形化展示执行计划时对“关联子查询依赖性分析”的临时标记。它不对应任何真实物理/逻辑操作符，本质是渲染层的提示性占位符。
常见触发场景是：当子查询引用了外部查询的列（即关联子查询），且该子查询被优化器判定为需要“逐行求值”（如 WHERE col IN (SELECT ... FROM t WHERE t.id = outer.id)），SQL Server 会在计划 XML 中记录依赖关系元数据，而 SSMS 把这部分结构误标为 Dependency_。
这不是错误，但容易让人误以为存在一个叫 Dependency_ 的执行步骤。实际执行时，SQL Server 会把它转成嵌套循环、连接重写，或展开为 APPLY 操作 —— 你看到的 Dependency_ 只是“这里有个跨作用域的引用”，不是运行时要执行的东西。
关联子查询的依赖关系如何影响执行计划生成
SQL Server 在编译阶段必须识别子查询是否真正“关联”，也就是是否引用了外部作用域的列。这个判断直接影响重写策略和性能：
- 若子查询不关联（如
WHERE id IN (SELECT id FROM lookup)），常被转为哈希/合并连接或半连接（Semi Join） - 若子查询关联（如
WHERE id IN (SELECT id FROM lookup WHERE lookup.type = outer.type)），可能保留为Nested Loops+Compute Scalar，或尝试用APPLY重写 - 如果关联列上没索引，且子查询返回多行，
Nested Loops可能导致严重性能退化 —— 这时候执行计划里“看似无害”的Dependency_提示，其实暴露了潜在的逐行扫描风险
注意：sys.sql_expression_dependencies 不会记录这种运行时动态关联依赖，它只跟踪静态定义中的对象名引用（比如视图里写了 SELECT * FROM dbo.users）。关联子查询的依赖是编译期推导的，不落盘到系统视图。
怎么确认是不是真有依赖问题，而不是 SSMS 渲染误导
别只看图形计划里的 Dependency_ 文字。直接查执行计划 XML 或使用以下方式验证：
- 右键图形计划 → “查看执行计划 XML”，搜索
RelOp节点，看PhysicalOp实际是什么（通常是Nested Loops、Compute Scalar或Apply） - 用
SET STATISTICS XML ON执行语句，观察EstimateRows和ActualRows是否严重偏离 —— 偏离大往往说明关联条件未有效驱动索引查找 - 对比改写为
INNER JOIN或CROSS APPLY后的计划：如果原语句有Dependency_，而改写后变成清晰的Hash Match或Index Seek，就说明原写法触发了低效路径
关键点：SQL Server 本身没有 Dependency_ 算子。它只是告诉你，“这儿有个跨作用域引用，我得小心处理”。真正要盯的是那个引用是否可索引、是否被正确重写、是否引发重复计算。
关联子查询依赖关系最容易被忽略的细节
最隐蔽的问题是：依赖关系可能被隐式“切断”而不报错。例如：
- 外部查询用了
NOLOCK，子查询没加，事务隔离级别不一致可能导致依赖失效或结果不一致 - 子查询里用了
TOP 1但没配ORDER BY，SQL Server 无法保证每次取同一行，表面有依赖，实际行为不可控 - 子查询引用了计算列或函数列（如
YEAR(order_date)），而该列上无统计信息，优化器可能放弃利用依赖关系做预估
这些都不会让 Dependency_ 消失，但会让它变成一个“假安全信号”——看起来有依赖分析，实际执行却绕过了所有优化假设。
