SQL Server视图需手动重编译才能生效，MySQL视图依赖DEFINER权限上下文，PostgreSQL普通视图实时解析、物化视图需手动刷新。
视图定义变更后查询仍用旧逻辑？
SQL Server 里改了 CREATE VIEW 的定义，但后续查询结果没变，甚至执行计划还显示老字段——不是缓存没清，是视图没重编译。SQL Server 不会自动重编译依赖视图的查询计划，哪怕你用 ALTER VIEW 更新了定义。
常见错误现象：SELECT * 查出的列数/类型和新视图定义不一致；sys.dm_exec_cached_plans 里还能查到引用旧列名的计划；修改视图后立刻查，结果却像没改过。
- 必须手动触发重编译：对视图执行
sp_recompile 'view_name' - 或清空整个计划缓存（生产慎用）：
DBCC FREEPROCCACHE - 如果视图被存储过程引用，仅重编译视图还不够，还得对调用它的存储过程也执行一次
sp_recompile
MySQL 视图没有重编译概念，但要注意 DEFINER 和 SQL SECURITY
MySQL 视图不编译、不缓存执行计划，每次查询都实时解析定义。所以“更新视图后逻辑没生效”大概率是权限或上下文问题，不是编译残留。
使用场景：视图里用了 CURRENT_USER() 或访问了某用户私有表，但调用者权限不足，就会静默返回空或报错 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。
-
DEFINER决定视图执行时的权限上下文，不是创建者当前登录用户 -
SQL SECURITY DEFINER（默认）按定义者权限跑；SQL SECURITY INVOKER才按调用者权限跑 - 改视图时若没显式指定
DEFINER，MySQL 可能自动设成当前用户，上线后因账号不存在直接失效
PostgreSQL 视图「刷新」只影响物化视图，普通视图永远实时
PostgreSQL 普通视图就是一条保存的查询语句，没有编译、没有缓存、没有重编译一说。每次 SELECT 都走一遍解析+规划+执行。所以改完 CREATE OR REPLACE VIEW，下一条查询就生效。
但注意：如果用的是物化视图（MATERIALIZED VIEW），它真有“过期”和“刷新”概念。改底层表结构后，不刷新物化视图会导致 refresh materialized view 失败，或查询时报错 relation "xxx" does not exist。
- 普通视图无需任何操作，改完即用
- 物化视图必须手动
REFRESH MATERIALIZED VIEW，且该操作会加锁阻塞读 - 物化视图不支持自动刷新，需配合定时任务或触发器模拟
跨引擎迁移时最容易忽略的视图行为差异
把 SQL Server 视图迁到 PostgreSQL，或者把 MySQL 视图搬到 SQL Server，最常踩的坑不是语法，而是对“视图何时绑定元数据”的理解偏差。比如在 SQL Server 中，视图创建时就硬编码了所引用列的 column_id，哪怕源表加了新列、删了旧列，只要不重编译，查询仍按老 ID 绑定——而 PostgreSQL 根本没有这层绑定。
- SQL Server：视图元数据在首次编译时固化列序和类型，依赖
sys.columns快照 - MySQL：依赖
DEFINER账号存在性，不检查列是否存在，直到真正执行才报错 - PostgreSQL：所有解析都在运行时，但物化视图刷新失败不会自动降级为普通视图，会直接中断
真正在意逻辑一致性的地方，别只信“改完视图就完事”，得看引擎怎么记这笔账。
