视图查询报错是因定义sql与基表结构不匹配，数据库不自动校验适配，执行时才暴露类型/字段名冲突；postgresql会阻断alter column并强制先删视图，mysql/sql server需手动比对元数据重写视图。
修改基表字段类型后视图查询报错，不是数据库“记仇”，而是视图定义里的 SQL 文本和当前基表结构对不上——它不校验、不预警、不自动适配，只在执行时硬碰硬地解析，一错就崩。
视图不感知基表类型变更，只认创建时写的SQL
视图本质是一段固化下来的 SELECT 语句（存于 information_schema.VIEWS.VIEW_DEFINITION 或 sys.sql_modules），数据库不会在每次查询前去比对基表字段的 system_type_id 或 max_length。哪怕你把 INT 改成 BIGINT，视图仍按旧类型元数据做列推导，直到执行时遇到类型冲突或隐式转换失败才报错。
- MySQL：查
SHOW CREATE VIEW v_name，复制里面的 SELECT 去单独执行，立刻暴露哪一行字段不匹配 - PostgreSQL：用
SELECT pg_get_viewdef('v_name')拿出定义，再\d base_table对字段名、类型逐个核对 - SQL Server：运行
SELECT OBJECT_DEFINITION(OBJECT_ID('v_name'))，然后查sys.columns确认基表对应列的system_type_id（如 56=INT，127=BIGINT）是否一致
ALTER COLUMN 直接被阻断：PostgreSQL 的强依赖机制
PostgreSQL 在创建视图时，会往 pg_depend 插入强依赖记录（deptype = 'n'）。一旦你对基表字段执行 ALTER COLUMN ... TYPE，它检测到视图依赖该字段，就会直接拒绝，报错类似：
ERROR: cannot alter type of a column used by a view or rule DETAIL: rule _RETURN on view "V_MM_StockInfo_Defective" depends on column "c_SpecificationAndModel"
这不是 bug，是保护机制——防止视图元数据与物理存储脱节导致静默错误。
- 必须先
DROP VIEW（或CREATE OR REPLACE VIEW），再改基表字段 - 若视图被其他对象引用（如物化视图、函数），需按依赖顺序从底向上重建
- 别指望
REFRESH MATERIALIZED VIEW能绕过，它一样会卡在依赖校验阶段
字段重命名或删列导致 “Unknown column” 报错
这类报错最常见，但最容易误判为权限或缓存问题。其实就一条：视图定义里写的字段名，在当前基表里已经不存在了。
- 典型场景：基表
dept_name改成department_name，视图里还写SELECT dept_name FROM t - MySQL 和 PostgreSQL 没有
sp_refreshview这类命令，所谓“刷新元数据”纯属无效操作 -
SELECT *是高危写法：加列后视图返回列数变多，应用按位置取值（如rs.getString(2)）会读错字段；删列则直接报Unknown column - 修复动作只能是显式重写视图：逐列映射，必要时加
COALESCE(col, 'N/A')或CASE WHEN兜底
真正麻烦的从来不是“改不了”，而是“改了也不报错却结果错”——比如 INT → BIGINT 不报错，但下游 Java 应用用 getInt() 取值可能溢出；VARCHAR(50) → VARCHAR(20) 不报错，但截断后业务逻辑失效。这种静默偏差，比立刻报错更难排查。
