应主动扫描视图定义中引用的列、表名、通配符及权限是否有效：检查列是否存在、表是否重命名、避免SELECT*、验证执行角色权限，优先使用系统目录依赖关系而非正则解析。
检查视图定义中引用的列是否在基表中真实存在
视图失效往往不是因为 DROP VIEW，而是基表改名、删列或改类型后，视图仍能创建成功（尤其在 PostgreSQL 或 SQL Server 中），但查询时才报错。关键是要在部署前主动扫描。
以 PostgreSQL 为例，可查 pg_views 获取定义文本，再用正则提取所有 schema.table.column 或 table.column 形式引用，然后逐个验证：
SELECT v.schemaname, v.viewname, m.match AS referenced_column
FROM pg_views v,
LATERAL (SELECT regexp_matches(v.definition, E'(\w+\.)*\w+\.(\w+)', 'g')) AS m(match)
WHERE v.schemaname NOT IN ('pg_catalog', 'information_schema')
AND NOT EXISTS (
SELECT 1 FROM pg_attribute a
JOIN pg_class c ON a.attrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE c.relname = split_part(m.match[1], '.', 2)
AND n.nspname = COALESCE(split_part(m.match[1], '.', 1), current_schema())
AND a.attname = m.match[2]
AND NOT a.attisdropped
);- 注意：该正则只捕获点号分隔的列引用，不处理子查询别名、函数调用或字符串字面量中的假匹配
- MySQL 不支持
LATERAL和复杂正则，需改用存储过程 +INFORMATION_SCHEMA.VIEWS+ 字符串拆分逻辑 - SQL Server 应优先用
sys.dm_exec_describe_first_result_set检查视图元数据，它会直接返回“列不存在”错误，比解析定义更可靠
识别视图定义中硬编码的表名与当前实际表名不一致
当表被重命名（如 ALTER TABLE users RENAME TO app_users）而视图未更新，pg_views.definition 里还留着旧名，运行时才会失败。
防御性做法是把视图依赖关系和当前对象名做双向比对：
SELECT DISTINCT
dep.objid::regclass AS view_name,
refobjid::regclass AS referenced_table,
pg_get_object_address('relation', refobjid::regclass::text::name, ARRAY[]::text[]) IS NULL AS table_missing
FROM pg_depend dep
JOIN pg_class c ON dep.classid = c.oid AND c.relname = 'pg_class'
WHERE dep.refclassid = 'pg_class'::regclass
AND dep.deptype = 'n' -- normal dependency
AND dep.objid IN (SELECT oid FROM pg_views WHERE schemaname = 'public');-
deptype = 'n'表示强依赖（非临时或自动创建），排除掉物化视图刷新触发的弱依赖 - 若
table_missing为true，说明该视图依赖一个已不存在的表名 —— 这比解析 SQL 文本更准，因它走的是系统目录快照 - Oracle 用户应查
ALL_DEPENDENCIES，但要注意STATUS = 'INVALID'是结果而非原因，需结合ALL_OBJECTS的OBJECT_NAME实时校验
避免视图中使用 * 导致新增列后语义漂移
SELECT * FROM users 在视图里看似省事，但后续给 users 加一列（如 updated_at），所有依赖该视图的应用可能意外多出一列，导致 INSERT/JOIN/ORDER BY 行为突变。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
检测脚本应标记所有含 * 的视图定义：
SELECT schemaname, viewname, definition FROM pg_views WHERE definition ~* 'SELECTs+*s+FROM';
- 正则用
SELECTs+*s+FROM避免误匹配注释或字符串内的* - 即使业务允许
*，也建议加注释说明：“此视图必须人工同步列列表”，否则 CI 流水线无法自动化校验 - SQL Server 中可用
sys.sql_modules替代pg_views，但需注意definition被截断为 4000 字符，长视图要拼接sys.dm_exec_describe_first_result_set辅助判断
跨 schema 视图依赖未授权访问路径引发权限静默失败
视图定义里写 SELECT id FROM other_schema.logs，但执行用户没有 other_schema.logs 的 SELECT 权限 —— 此时视图本身可创建成功，但运行时报 permission denied for table logs，且错误不提示具体缺失权限对象。
防御性检查必须模拟执行者权限：
- PostgreSQL：用
SET ROLE切换到目标角色后执行SELECT * FROM view_name LIMIT 0，捕获异常 - 不要仅查
pg_authid和pg_class的relacl，因权限可能来自角色继承或DEFAULT PRIVILEGES - 自动化脚本中，最稳妥的方式是让 DBA 提供一组典型执行角色，逐一测试
pg_has_role(role, 'USAGE')+has_table_privilege(role, 'other_schema.logs', 'SELECT')
真正难的不是写检测逻辑，而是把视图的“预期执行上下文”固化下来 —— 比如哪个角色该有哪张表的读权限，这些规则一旦脱离代码，就只能靠人肉核对。
