SQL存储过程依赖关系混乱的解决方法

许多数据库管理员在排查SQL Server存储过程的依赖关系时，常常面临一个棘手局面：使用系统视图查询依赖，结果却是空值或信息残缺不全。不必急于怀疑工具出了问题——首先应当检查对象创建时依赖项是否存在、是否采用了动态SQL、数据库上下文是否正确，或者是否被加密与权限限制所阻碍。要真正梳理清楚存储过程的依赖关系，必须将系统视图查询、字符串扫描和手动验证三者有机结合，缺一不可。

查依赖时返回空或不全，先确认视图和上下文

sys.sql_expression_dependencies 返回空结果，并不代表实际不存在依赖关系。大概率是对象创建时依赖项尚未建立、代码中使用了动态SQL，或者当前数据库上下文不正确。该视图仅记录“显式、静态、可解析”的引用，且要求被引用对象在 CREATE PROC 时已经存在并能够被成功解析。换句话说，它只处理编译期可以确定的内容。

• 执行查询前务必 USE 存储过程所在的数据库，否则 referenced_database_name 可能返回 NULL 或出现错误
• 检查是否使用了 WITH ENCRYPTION 选项——加密后该视图无法读取内容，会直接返回空行
• 如果 is_ambiguous = 1，表明存在名称冲突或权限不足。例如同名表出现在多个 schema 下，或者当前用户缺少 VIEW DEFINITION 权限
• 不要仅依赖 sys.sql_expression_dependencies，它会遗漏动态部分；建议配合 sys.dm_exec_describe_first_result_set_for_object（SQL Server 2012+）一起使用

动态 SQL 的依赖根本不会进系统视图，得手动扫字符串

动态SQL？那就更不要指望系统视图了。EXEC(@sql) 或 sp_executesql 中的对象名，SQL Server 在编译期完全不解析——所有依赖分析工具都会忽略它。这并非bug，而是设计如此。

• 使用 OBJECT_DEFINITION(OBJECT_ID('proc_name')) 获取完整文本，再进行正则匹配：EXECs+[?(w+)]?、INSERTs+INTOs+[?(w+)]?、FROMs+[?(w+)]?
• 匹配出的名称需要通过 OBJECT_ID(name) 验证，排除拼写错误、临时表（如 #temp）、表变量（@table）——它们虽然不会出现在任何依赖视图中，但运行时确实会引发错误
• 特别注意 tempdb..#t 这种三段式写法：虽然指定了数据库名，但 tempdb 属于运行时上下文，sys.sql_expression_dependencies 从不记录此类依赖

跨库引用显示 NULL？不是数据丢了，是默认按当前库解析

如果存储过程中写了 OtherDB.dbo.TableA，sys.sql_expression_dependencies.referenced_database_name 很可能仍然是 NULL。不必认为是数据丢失，这实际上是SQL Server解析器的默认行为：它按照当前会话的默认数据库进行解析，不会主动跨库解析名称。

• 确保查询依赖时连接的是该存储过程所属数据库（例如过程在 DB1，就执行 USE DB1 再查询）
• 如果仍为 NULL，可以手动补全：使用 referenced_entity_name + referenced_schema_name 拼接完整对象名，再通过 DB_NAME() 和 SCHEMA_NAME() 验证是否存在
• 避免省略数据库名的写法（如 dbo.TableA），这种写法在跨库场景下极易导致部署后运行时出现 Invalid object name 错误

依赖“丢失”了？可能是延迟绑定没刷新，得手动重建元数据

还有一种常见情况：存储过程先创建完成，依赖的对象后续才创建，例如先创建 usp_A 再创建 usp_B。此时SQL Server不会自动补全依赖关系，sp_depends 和系统视图都无法查询到。这不是缓存问题，而是元数据根本未曾生成。

• 执行 sys.sp_refreshsqlmodule 'dbo.usp_A' 强制重新解析，它会重新扫描定义体并更新 sys.sql_expression_dependencies
• 批量刷新所有存储过程：对每个 type = 'P' 的 sys.objects 执行一次 EXEC sys.sp_refreshsqlmodule（注意避免在高负载时段运行）
• 刷新后仍然查询不到？说明代码中使用了 EXEC('...') 或对象名拼接 —— 这类依赖永远无法被自动捕获，只能依靠字符串扫描

依赖关系混乱的本质，并非工具不够好用，而是SQL Server将“静态可解析”与“运行时才确定”严格区分开来。越是依赖动态拼接、跨库引用、临时对象，就越需要放弃全自动方案，转而采用定义提取 + 字符串分析 + 人工验证三件套。这一点无法回避。