sys.sql_expression_dependencies是唯一靠谱的依赖关系数据源，它基于元数据解析，支持批量、跨库、过滤，不依赖注释匹配，能准确记录显式引用，但无法捕获动态sql中的运行时依赖。
不能靠 SSMS 点点点生成依赖关系图，那玩意儿只支持手动拖表、最多几十个对象，面对成百上千个视图直接卡死或报错。
sys.sql_expression_dependencies 是唯一靠谱的数据源
SSMS 里右键“查看依赖关系”底层调的就是这个系统视图，但它比 UI 稳定、可批量、可跨库、能过滤。关键它不依赖注释匹配，也不吃动态 SQL 的亏——只要视图定义里 SELECT 或 FROM 显式引用了某个对象，就会被记录。
-
referenced_id是被依赖对象（比如你要查的视图）的 object_id -
referencing_id是调用方（存储过程、函数、其他视图）的 object_id - 必须 JOIN
sys.all_objects才能拿到类型（type_desc），否则全是 ID，没法区分是 SP 还是 VIEW - 加
AND o.is_ms_shipped = 0排除系统对象，不然结果里混一堆fn_*和sp_*
导出为 CSV 或 Excel 的实际命令模板
别开 SSMS 图形界面导，直接用 sqlcmd 命令行跑脚本，避免内存溢出和超时：
sqlcmd -S your_server -d your_db -E -Q "SET NOCOUNT ON; SELECT DISTINCT OBJECT_SCHEMA_NAME(d.referencing_id) AS schema_name, OBJECT_NAME(d.referencing_id) AS object_name, o.type_desc AS object_type, OBJECT_SCHEMA_NAME(d.referenced_id) AS ref_schema, OBJECT_NAME(d.referenced_id) AS ref_name FROM sys.sql_expression_dependencies d JOIN sys.all_objects o ON d.referencing_id = o.object_id WHERE d.referenced_id IN (SELECT object_id FROM sys.views WHERE is_ms_shipped = 0) AND o.is_ms_shipped = 0 ORDER BY ref_name, object_type;" -o "view_dependencies.csv" -s "," -w 1024
-
-s ","指定字段分隔符为逗号，Excel 能直接识别 -
-w 1024防止字段截断（尤其视图名带空格或特殊字符） - 如果导出为空，先确认是否漏了
WHERE d.referenced_id IN (...)——不加这句只会查单个视图，不是“所有视图”的依赖
动态 SQL 引用的视图怎么补？
如果某视图 A 里有 EXEC('SELECT * FROM ' + @tbl) 这种拼接表名的写法，sys.sql_expression_dependencies 就不会记录 A 对 @tbl 的依赖——因为编译期根本不知道 @tbl 是啥。这时候只能人工兜底：
- 用
OBJECT_DEFINITION(object_id)把所有视图定义拉出来，再用正则匹配FROM\s+[\[\]\.\w]+或JOIN\s+[\[\]\.\w]+ - 注意排除注释行：SQL Server 注释是
--和/* */，不处理会把注释里的视图名也当真 - 这种扫描建议在维护窗口跑，
OBJECT_DEFINITION()对每个对象都触发一次元数据读取，上千个视图会明显拖慢服务器
真正难的不是查依赖，而是理清“谁改了谁”。比如一个视图 B 依赖视图 A，而 A 又依赖表 T；但 A 被设了 SCHEMABINDING，你动不了 T。这种链式约束必须一层层展开看，光导出二维表格没用——得把结果导入图数据库或用 Python 的 networkx 建图，否则看不出闭环或断裂点。
