sql server中查视图依赖对象应优先使用sys.sql_expression_dependencies，因其基于元数据解析，准确记录跨库跨schema引用；sys.dm_exec_describe_first_result_set仅解析首层静态语句，无法跟踪动态sql、嵌套视图及跨库依赖链。
SQL Server 中查视图依赖对象用 sys.dm_exec_describe_first_result_set 不可靠
直接查 sys.dm_exec_describe_first_result_set 会漏掉动态 SQL、嵌套视图、跨库引用，甚至根本返回空结果。它只解析首层静态语句，不跟踪实际执行时的依赖链。
真正能覆盖多数场景的是 sys.sql_expression_dependencies —— 它记录了 CREATE/ALTER 时 SQL Server 解析并持久化的依赖关系，只要对象是用标准 DDL 创建的（非拼接字符串），基本都可查到。
-
sys.sql_expression_dependencies的referencing_id是调用方（比如存储过程 ID），referenced_id是被依赖方（比如你的视图 ID） - 反过来查“谁依赖我”，得用
referenced_id = OBJECT_ID('your_view_name') - 注意：如果视图被重命名或重建过，旧依赖可能残留；新依赖在下次 ALTER 后才更新
PostgreSQL 查视图依赖必须用 pg_depend 配合 pg_class
PostgreSQL 没有开箱即用的“谁用了我”视图，pg_views 只存视图定义，不存反向引用。必须手动关联系统表：
SELECT DISTINCT
n.nspname AS schema_name,
c.relname AS dependent_object_name,
c.relkind AS type
FROM pg_depend d
JOIN pg_class c ON d.refobjid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE d.objid = 'your_view_name'::regclass
AND d.refobjsubid = 0
AND c.relkind IN ('v', 'm', 'f', 'p');
关键点：
-
'your_view_name'::regclass确保名称被正确解析为 OID，避免大小写或 schema 错误 -
d.refobjsubid = 0过滤列级依赖（比如只依赖某几列），这里要的是对象级依赖 - 结果中
relkind = 'v'是视图，'m'是物化视图，'f'是函数，'p'是分区表 —— 视图可能被这些类型直接引用
MySQL 8.0+ 只能靠 information_schema.ROUTINES 和正则硬匹配
MySQL 没有原生依赖追踪机制。视图依赖可从 information_schema.VIEWS 查（因为视图定义存在 VIEW_DEFINITION 字段），但存储过程、函数、触发器里的引用必须搜源码：
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM information_schema.ROUTINES WHERE ROUTINE_DEFINITION REGEXP '(?i)\bYOUR_VIEW_NAME\b';
风险点很实在：
- 正则匹配容易误伤，比如视图名
user_info会匹配到user_info_log或变量@user_info - 如果 ROUTINE_DEFINITION 被加密（
CREATE PROCEDURE ... WITH ENCRYPTION），这条就完全失效 - MySQL 8.0.29+ 才支持
ROUTINE_DEFINITION字段；更低版本只能靠SHOW CREATE PROCEDURE逐个查
跨数据库迁移时依赖检查最容易漏掉权限和同义词
查出所有调用方只是第一步。真实上线常卡在：SELECT * FROM your_view 能跑，但下游应用报 “permission denied” 或 “relation does not exist”。原因往往是：
- Oracle 中依赖视图的对象可能通过同义词访问，而
dba_dependencies默认不包含同义词解析路径，得额外查dba_synonyms并 join - PostgreSQL 的
SECURITY DEFINER函数可能以 owner 权限执行，导致依赖视图时实际走的是 owner 的 search_path，而非调用者路径 - SQL Server 的
EXECUTE AS上下文切换会让依赖解析脱离当前用户 schema，需用sys.dm_exec_plan_attributes看实际执行计划中的 resolved object
依赖关系不是静态快照，它是定义时解析、运行时生效的混合体。尤其当视图里有 CROSS APPLY、OPENQUERY 或链接服务器引用时，工具查到的只是表面，真正调用链得看实际执行计划的 ObjectID。
