不能直接用sys.dm_exec_describe_first_result_set查视图是否失效，它仅分析元数据且不校验依赖，视图引用的表被删时会直接报错而非返回失效状态。

SQL Server 里 sys.dm_exec_describe_first_result_set 能不能查视图是否失效？

不能直接用。这个函数只分析语句的元数据，不实际执行、也不校验依赖对象是否存在。如果视图引用的表已被删掉，调用它时会直接报错：Invalid object name 'xxx'，而不是返回“失效”状态。

真正能触发检查的，是尝试访问视图本身或用系统存储过程验证定义。

• 最轻量的方法：对视图执行 SELECT TOP 0 * —— 它不取数据，但会走完整解析和权限校验路径
• 更彻底的方法：用 sp_refreshview 尝试刷新；失败即说明依赖断裂
• sp_depends 已弃用，且不反映跨库/跨架构依赖，别依赖它

PostgreSQL 怎么快速发现 view 引用的表或列丢了？

PostgreSQL 在视图创建时不做严格依赖检查，所以删了底层表，pg_views 里视图记录还在，但查询会报 relation "xxx" does not exist 或 column "yyy" does not exist。

靠人工巡检不现实，得用系统视图组合查：

• 查所有视图定义：SELECT schemaname, viewname, definition FROM pg_views
• 结合 pg_depend 和 pg_class 反向追踪依赖对象是否存在（注意：只覆盖同库内对象）
• 简单粗暴但有效：在维护窗口批量运行 SELECT 1 FROM schema.view_name LIMIT 0，捕获异常即可定位失效视图

MySQL 8.0+ 的 information_schema.VIEWS 能不能判断视图有效性？

不能。这个表只存 VIEW_DEFINITION 和创建时间，不记录依赖状态。MySQL 不像 SQL Server 那样提供视图刷新机制，一旦底层表被重命名或删掉，首次查询视图就会报错：Table 'db.xxx' doesn't exist。

检测必须主动触发解析：

• 用 SHOW CREATE VIEW view_name 拿到定义后，手动提取 FROM 和 JOIN 后的表名，再查 information_schema.TABLES 确认存在
• 写个脚本循环执行 SELECT * FROM view_name WHERE 1=0（比 TOP 0 兼容性更好），捕获 ERROR 1146 类错误
• 注意：MySQL 对列不存在的错误（如字段改名）不报在预编译阶段，要等真正 SELECT 才暴露

跨数据库或含函数/CTE 的视图，为什么常规检测总漏掉？

因为依赖不是静态可枚举的。比如视图里调用 my_udf()，而该函数体里又动态拼接表名；或者 CTE 中用了 UNION ALL 混合了不同来源的表——这些场景下，pg_depend、sys.sql_expression_dependencies 都可能无法完整建模。

这类视图只能靠“运行时探活”：

• 把视图纳入例行健康检查 SQL 脚本，统一加 LIMIT 1 或 WHERE 1=0 包裹
• 避免在生产高峰期跑全量检测，优先在从库或备份实例上执行
• 日志里重点抓取 relation not found、invalid column reference、function does not exist 这三类错误码

依赖链越深、越动态，就越难靠静态分析兜底。真要防住，得在 DDL 变更流程里卡住：删表前先跑一遍依赖扫描，而不是等视图崩了才去救火。