不能直接用information_schema.VIEWS判断视图是否失效，因其仅存储VIEW_DEFINITION等静态元数据，不校验依赖对象是否存在；视图引用的表被删后，该表记录仍存在且定义不变，须主动执行SELECT * FROM view WHERE 1=0并捕获ERROR 1146等异常才能发现失效。
information_schema.VIEWS 不能判断视图是否失效，它只存定义和元数据，不校验依赖。
直接查 information_schema.VIEWS 为什么不行
information_schema.VIEWS 表里每条记录都包含 VIEW_DEFINITION 和 CHECK_OPTION 等字段，但完全不反映底层对象是否存在。
- 视图引用的表被
DROP TABLE后，该视图在VIEWS中依然存在，VIEW_DEFINITION字段内容也不变 - 查询该视图时才会真正报错：
Table 'db.xxx' doesn't exist（MySQL 8.0+）或ERROR 1146 - 所以靠 SELECT 查询
VIEWS表本身，永远得不到“失效”状态
MySQL 没有内置的“视图健康检查”命令
不像 SQL Server 的 sp_refreshview 或 PostgreSQL 的 pg_depend 可反向追踪，MySQL 不维护运行时依赖图谱。
- 它在创建视图时只做语法解析，不预编译、不绑定对象 OID
- 对列名变更、函数体改动、CTE 中动态表名等场景，连语法检查都跳过
最实用的检测方式：用 SELECT ... WHERE 1=0 主动触发解析
这是目前最轻量、兼容性最好、能覆盖多数失效场景的方法：
-
WHERE 1=0比LIMIT 0更可靠：所有 MySQL 版本都支持，且强制走查询解析器全链路（包括权限校验、表存在性检查、列存在性检查） - 不取数据，开销极低
- 脚本中捕获
ERROR 1146（表不存在）、ERROR 1054（列不存在）、ERROR 1356（视图定义不可用）即可定位问题
SELECT * FROM your_schema.your_view WHERE 1=0;
容易被忽略的复杂点
- 如果视图定义里用了跨库名（如
other_db.table），而当前用户对该库无权限，WHERE 1=0也会失败，但这不是“失效”，是权限问题 - 含自定义函数的视图：函数体若引用了已删表，错误只在函数执行时抛出，
WHERE 1=0可能不触发——必须实际执行一次（哪怕SELECT 1 FROM view LIMIT 1） -
SQL SECURITY DEFINER视图：检查时得用定义者身份连接，否则权限校验路径不同，结果不可信
真正有效的检测，永远需要主动执行一次解析动作；寄希望于元数据表返回“健康状态”，在 MySQL 里是走不通的。
