视图能解决字段名变更、类型收缩、表拆分/合并等结构不兼容问题。它通过封装查询逻辑提供轻量兼容层，使旧应用无需改代码即可继续运行原SQL。
视图能解决迁移中哪些表结构不兼容问题
视图本身不存储数据，只保存查询逻辑，所以它是构建兼容层最轻量的手段。当目标库字段名变更、类型收缩（如 VARCHAR(255) → VARCHAR(100)）、或拆分/合并表时，用视图可让旧应用继续执行原 SQL，无需改代码。
典型场景包括：MySQL 迁移至 PostgreSQL 时处理 TEXT vs LONGTEXT 差异；从单表 users 拆出 user_profiles 后，用视图拼回兼容字段；或者为兼容老应用的 is_deleted 布尔字段，在新库用 deleted_at IS NULL 计算。
创建兼容视图时必须绕开的三个陷阱
视图不是万能胶，硬套会引发隐性故障：
- 避免在视图里用
SELECT *：源表加字段后，视图列顺序/数量可能意外变化，导致下游INSERT INTO ... SELECT或 ORM 映射失败 - 慎用
CAST强转类型：PostgreSQL 中CAST(created_at AS DATE)在视图里看似正常，但若上层应用依赖毫秒精度，就会丢数据且难以定位 - 不要在视图里写业务逻辑分支：比如
CASE WHEN status = 'A' THEN 'active' ELSE 'inactive'—— 这类映射应由应用或中间层控制，否则迁移后期清理成本极高
跨数据库创建视图的语法差异要点
MySQL、PostgreSQL、SQL Server 对视图支持程度不同，关键差异集中在权限和定义灵活性：
- MySQL 8.0+ 支持
CREATE OR REPLACE VIEW，但老版本必须先DROP VIEW；PostgreSQL 原生支持OR REPLACE - SQL Server 要求视图定义中所有列必须有明确别名，否则建视图失败；PostgreSQL 允许推导，但建议显式写
AS避免歧义 - Oracle 视图不支持直接引用同义词（synonym），而 PostgreSQL 可以；若迁移涉及 Oracle，需提前把同义词替换成真实表名再建视图
示例（PostgreSQL 兼容 MySQL 的 datetime 字段）：
CREATE OR REPLACE VIEW users_compat AS
SELECT id, name,
created_at AT TIME ZONE 'UTC' AS created_at,
COALESCE(deleted_at, '9999-12-31')::TIMESTAMP AS deleted_at
FROM users;
视图性能与可维护性边界在哪
视图只是查询封装，不加速也不缓存。一旦底层表大、JOIN 多、或含复杂计算，每次查视图都等于重跑整个查询 —— 这在迁移过渡期容易暴露成性能瓶颈。
- 简单映射（字段重命名、NULL 替换）基本无开销；含
JOIN或子查询的视图，务必在关联字段上建索引 - 不要用视图替代物化视图（如 PostgreSQL 的
MATERIALIZED VIEW）来“优化”—— 物化视图需手动刷新，违背兼容层“自动同步”的初衷 - 上线前用
EXPLAIN ANALYZE对比视图查询和等价原始查询的执行计划，确认没引入额外嵌套或全表扫描
真正难的是生命周期管理：没人记得删掉迁移完成后的兼容视图，它们会变成数据库里的幽灵依赖，下次重构时突然报错。
