视图仅支持读场景平滑过渡，写操作需应用层路由或触发器；因视图是查询快照而非真实表，MySQL严格限制可更新视图（单表、无聚合、无子查询等），PostgreSQL虽支持INSTEAD OF触发器但需手动实现且不可跨库。
视图能帮你稳住旧系统接口，但只在读场景下真正“平滑”——写操作必须绕开视图走应用层路由或触发器，否则立刻报错。
为什么直接用视图替代旧表会失败
常见错误现象：ERROR: cannot insert into a view（PostgreSQL）、View's SELECT contains a subquery in the FROM clause（MySQL）。这是因为视图本身不存数据，数据库默认禁止对复杂查询结果做写入。即使你定义了 CREATE VIEW v_users AS SELECT * FROM new_users，只要底层有字段改名、拆分、类型变化，或者用了 COALESCE、CASE、JOIN，MySQL 就直接拒绝 INSERT INTO v_users；PostgreSQL 虽支持 INSTEAD OF 触发器，但得手动写，且不能复用到 MySQL。
关键点在于：视图不是表的别名，而是查询快照。它不接管 DML，只翻译 SELECT。
- MySQL 对可更新视图限制极严：必须单表、无聚合、无子查询、无计算列、无
DISTINCT - PostgreSQL 允许通过
INSTEAD OF触发器拦截写操作，但需为每个视图单独实现逻辑，且无法跨库转发 - 所有数据库都要求视图定义中字段必须显式列出，禁用
SELECT *，否则新增字段会意外透出，破坏旧系统契约
如何让旧 SQL 语句继续跑通（SELECT 场景）
核心是字段对齐 + 类型兜底。旧系统调用的是 SELECT id, user_name, is_active FROM users，而新表可能是 users_v2(id, first_name, last_name, status)，这时视图就得把语义“翻译”回来：
示例（PostgreSQL/MySQL 均适用）：
CREATE VIEW users AS SELECT id, COALESCE(first_name || ' ' || last_name, user_name) AS user_name, CASE WHEN status = 'active' THEN 1 ELSE 0 END AS is_active FROM users_v2 FULL JOIN legacy_users ON users_v2.id = legacy_users.id;
实操建议：
- 用
COALESCE(new_col, old_col)处理迁移过渡期双写导致的 NULL 空缺，但注意：如果old_col允许 NULL 而new_col是NOT NULL，得补默认值，比如COALESCE(status, 'inactive') - 字段类型不一致时，统一转宽泛类型，如
CAST(status AS TEXT)或CONVERT(VARCHAR(255), status)，避免隐式转换失败（PostgreSQL 对TEXT和CHAR比较敏感） - 避免在视图里用
UNION或多层嵌套子查询，MySQL 优化器可能放弃使用索引，导致全表扫描旧表
写操作必须由应用层控制路由
别指望 INSERT INTO users 自动落到新表。视图上写入要么被拒，要么行为不可控。真实迁移中，写路径必须明确切分：
- 历史数据补全阶段：用 ETL 工具或脚本从旧表批量同步到新表，不经过视图
- 双写阶段：应用代码判断当前是否启用新结构，
INSERT同时写legacy_users和users_v2，视图仅用于读 - 灰度切换阶段：按用户 ID 或时间范围分流，比如
id % 100 < 10写新表，其余仍写旧表，视图保持全量查询能力 - 收尾阶段：停写旧表后，删掉
FULL JOIN中的 legacy_users 分支，视图退化为单纯 alias
PostgreSQL 用户若真想用视图承接写操作，必须为每个视图单独定义 INSTEAD OF INSERT 触发器，并在里面手写插入逻辑——但这已超出“轻量兼容层”的范畴，接近重写 DAO 层。
MySQL 用户特别注意算法与性能陷阱
MySQL 默认用 UNDEFINED 算法创建视图，遇到含 JOIN 或函数的视图，优化器可能放弃物化，每次查询都重新执行底层 SELECT，如果底层还连着旧大表，性能会断崖下跌。
实操建议：
- 用
CREATE ALGORITHM = MERGE VIEW ...强制合并，让优化器尽可能把条件下推到基表（但要求视图逻辑足够简单） - 避免在视图定义中引用未建索引的旧表字段，否则
WHERE user_name LIKE '%abc%'可能触发全表扫描 - 上线前务必在目标环境执行
EXPLAIN SELECT * FROM users WHERE id = 123，确认实际访问的是新表索引，而不是旧表全扫
最易被忽略的一点：视图字段别名一旦定死，就不能靠 ALTER VIEW 改名——MySQL 不支持 ALTER VIEW 修改列定义，只能 DROP + CREATE，而这个瞬间会导致正在执行的查询失败。所以字段映射务必一步到位，上线前用测试 SQL 跑满所有旧接口路径。
