应优先使用 sys.sql_expression_dependencies 查视图被哪些存储过程引用，因其基于元数据解析，能准确识别架构前缀、别名等静态引用，但无法捕获动态SQL拼接的运行时引用；也可用 sys.dm_sql_referencing_entities，但必须传入三段式名称（如'dbo.V_SalesSummary'）且参数类型为'OBJECT'。
查视图被哪些存储过程引用，优先用 sys.sql_expression_dependencies
sys.sql_expression_dependencies 是 SQL Server 2008+ 推荐的依赖查询方式，它基于元数据解析，不依赖文本匹配，能正确识别带架构前缀、别名、动态拼接等场景下的引用关系。
- 它不会漏掉
SELECT * FROM dbo.MyView这类写法，也不会把表名和视图名撞车（比如视图叫OrderView，但某存储过程中有WHERE Status = 'OrderView'）误判为引用 - 但对
WITH ENCRYPTION加密的存储过程，它仍能返回依赖（因为加密不影响元数据注册） - 注意：该视图只记录“创建时已知”的依赖；如果存储过程里用
EXEC('SELECT ... FROM ' + @viewname)拼接视图名，这种运行时动态引用不会被收录
示例查询（查视图 V_SalesSummary 被哪些存储过程引用）：
SELECT
OBJECT_SCHEMA_NAME(referencing_id) AS [Schema],
OBJECT_NAME(referencing_id) AS [ObjectName],
o.type_desc AS [ObjectType]
FROM sys.sql_expression_dependencies d
INNER JOIN sys.objects o ON d.referencing_id = o.object_id
WHERE d.referenced_entity_name = 'V_SalesSummary'
AND o.type IN ('P', 'TR', 'FN', 'IF', 'TF')
ORDER BY [Schema], [ObjectName];
sys.dm_sql_referencing_entities 更直接，但要求传入完整三段式名称
这个函数是“反向查”的快捷入口，适合快速验证单个对象的上游调用方。但它对参数格式很敏感：
- 必须传入三段式名称：
'dbo.V_SalesSummary'，不能只写'V_SalesSummary' - 第二个参数固定为
'OBJECT'，大小写不敏感但字符串必须准确 - 返回结果字段比
sys.sql_expression_dependencies少，但包含is_schema_bound_reference（是否架构绑定）这类关键标志
常见错误现象：
- 执行
SELECT * FROM sys.dm_sql_referencing_entities('V_SalesSummary', 'OBJECT')返回空 —— 因为没加 schema - 执行
SELECT * FROM sys.dm_sql_referencing_entities('Sales.dbo.V_SalesSummary', 'OBJECT')报错 —— 因为数据库名不能出现在第一个参数里
正确用法：
SELECT
referencing_schema_name,
referencing_entity_name,
referencing_id,
is_schema_bound_reference
FROM sys.dm_sql_referencing_entities('dbo.V_SalesSummary', 'OBJECT');为什么不用 syscomments 或 sys.sql_modules.definition LIKE '%...%'
这两种方式本质都是字符串搜索，问题集中且高频：
-
syscomments在 SQL Server 2005+ 已被标记为“仅用于向后兼容”，内容可能截断（每行最多 4000 字符），且对加密对象返回 NULL -
sys.sql_modules.definition虽然完整，但：- 会匹配注释里的表名或视图名（比如
-- 这里本该用 V_SalesSummary，但暂时注释掉） - 对大小写不敏感的排序规则下，
LIKE '%salessummary%'可能误中sales_summary_log这种无关对象 - 无法区分
FROM V_SalesSummary和JOIN V_SalesSummary s ON ...中的别名引用（后者其实没真正用到视图逻辑）
- 会匹配注释里的表名或视图名（比如
更麻烦的是：如果视图名含下划线、点号或被括起来（如 [dbo].[V_SalesSummary]），单纯 LIKE 很难覆盖所有变体，容易漏查。
加密存储过程不影响依赖查询，但要注意刷新统计
WITH ENCRYPTION 的存储过程，在创建/修改时仍会向 sys.sql_expression_dependencies 注册依赖关系 —— 这是 SQL Server 内部行为，和源码是否可见无关。
不过有个易忽略点：
如果视图本身被重命名、或其引用的底层表结构变更后未重新创建视图，SQL Server 有时不会自动更新依赖缓存。此时可手动执行：
EXEC sp_refreshsqlmodule 'dbo.V_SalesSummary';
这会强制重新解析视图定义，并同步更新所有依赖记录。不执行这步，sys.dm_sql_referencing_entities 可能返回过期结果。
真实运维中，多数人卡在第一步——传错对象名格式，或没意识到加密对象其实“查得到”。只要路径写对、函数选准，依赖关系基本是可靠的。
