不能直接用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 变更流程里卡住：删表前先跑一遍依赖扫描，而不是等视图崩了才去救火。
