在 SQL Server 中删除视图前，最让人担忧的是什么？不是删除失败，而是删除后才发觉某个存储过程正依赖该视图。届时后悔莫及。因此，事先查明哪些对象引用了该视图，是必不可少的前置步骤。
直接查询 sys.sql_expression_dependencies 是最可靠的方案，切勿使用 sp_depends 或 INFORMATION_SCHEMA.VIEWS ——这两者或已过时，或无法返回跨架构/动态 SQL 的引用信息。
查询视图被哪些存储过程引用（含架构信息）
SQL Server 在删除视图时不会自动阻断依赖关系，但你需要提前知晓哪些对象调用了它。核心是查询依赖关系系统表，而非仅查看视图定义本身。
sys.sql_expression_dependencies是首选：它记录了编译时解析出的显式引用，支持跨数据库查询（只要未使用动态 SQL 拼接视图名）- 必须使用
OBJECT_ID('dbo.v_orders')作为referencing_id参数，不能仅传递视图名字符串 - 结果中的
referenced_entity_name是被引用的对象名称，而referencing_entity_name才是你要查找的“谁引用了它”
示例：查询视图 v_orders 被哪些存储过程调用
SELECT
SCHEMA_NAME(o.schema_id) AS referencing_schema,
o.name AS referencing_name,
o.type_desc AS referencing_type
FROM sys.sql_expression_dependencies d
JOIN sys.objects o ON d.referencing_id = o.object_id
WHERE d.referenced_id = OBJECT_ID('dbo.v_orders')
AND o.type IN ('P', 'PC'); -- P=存储过程，PC=CLR 存储过程
为什么 sp_depends 不准确且已被弃用
它依赖于旧的 sysdepends 表，而该表自 SQL Server 2005 之后就不再实时更新。遇到以下情况时必然遗漏：
- 存储过程中使用了
EXEC('SELECT * FROM v_orders')这类动态 SQL - 视图位于其他数据库，而
sp_depends默认仅查询当前数据库 - 存储过程在创建后又经过 ALTER 修改，但
sysdepends未刷新
执行 sp_depends 'v_orders' 可能返回空结果，但这不代表没有被引用——只是它未能记录而已。
生产环境删除视图前必须执行的三项操作
仅查询依赖关系还不够，还需要验证实际影响：
- 在事务中执行一次
SELECT TOP 1 * FROM v_orders，确认该视图仍可正常查询，避免删除操作被 BI 工具或定时任务中断 - 使用
sys.dm_exec_describe_first_result_set检查下游视图是否隐式依赖该视图（例如SELECT * FROM v_orders被嵌套在另一个视图中） - 搜索代码库以及 BI 工具导出的元数据 JSON：许多团队将视图名称硬编码在 Power BI 数据集、SSIS 包或应用配置文件中，系统表根本无法记录这些外部引用
真正棘手的并非语法错误，而是删除后发现报表无法刷新数据、ETL 任务静默失败——因为错误日志中仅显示“invalid object name”，完全无法追溯到具体是哪个被删除的视图引发的。
