union all视图要求列数、顺序、类型三者严格一致，否则建视图直接报错；需显式写字段、用cast/::统一类型、补null占位、逐个检查索引，且字段顺序错一位即失败。
视图用 UNION ALL 合并多个表，不是“把字段名对上就行”的简单拼接——列数、顺序、类型三者必须严格一致，否则建视图直接报错，比如 ERROR: UNION types text and integer cannot be matched。
UNION ALL 视图建不起来？先检查列对齐和类型兼容性
错误往往出现在“看起来一样，实际不兼容”：比如 users.id 是 INTEGER，而 profiles.uid 是 TEXT，哪怕都叫 id，UNION ALL 也会拒绝。视图不自动做隐式转换。
- 所有
SELECT子句必须显式写出字段，禁用*—— 表结构一变，视图就失效 - 用
::或CAST()强制统一类型，例如id::BIGINT、name::TEXT - 字段别名只认第一个
SELECT的AS定义，后续子句即使写AS也不影响最终视图列名 - 空值补位要主动写，比如某表没
status字段，就得补NULL::TEXT AS status
视图查得慢？问题不在 UNION ALL，而在底层表缺索引
视图本身不存数据，每次查询都会重跑全部子查询。如果某个 SELECT 里有 WHERE status = 'active' 却没给 status 建索引，就会全表扫描——合并十张表，等于扫十次全表。
- 逐个检查每个
SELECT中的WHERE条件字段是否已建索引 - 若常按
created_at排序或分页（如ORDER BY created_at LIMIT 20），对应表的created_at字段建议加索引 - PostgreSQL 中可对视图字段加表达式索引，但更推荐在源表上建基础索引
MySQL 和 PostgreSQL 对 UNION ALL 视图的支持差异很实际
MySQL 8.0+ 允许标准 UNION ALL 视图，但禁止在视图定义中使用变量或子查询作为 FROM；PostgreSQL 更灵活，支持 CTE、窗口函数，但也更严格校验类型兼容性——同一字段在不同子句中用 TEXT 和 CHAR(10) 混用，PG 会报错，MySQL 可能默默转成 TEXT。
- 跨数据库迁移视图前，务必验证每个子查询能否独立执行且返回结构一致
- PG 的物化视图（
MATERIALIZED VIEW）不自动刷新，REFRESH MATERIALIZED VIEW是阻塞操作，高频更新场景慎用 - MySQL 不支持物化视图，纯逻辑视图，性能完全依赖源表优化
最容易被忽略的是字段顺序——哪怕所有字段名、类型都对得上，只要第二张表的 SELECT 把 email 写在 name 前面，整个 UNION ALL 就崩。类型强制转换和列顺序对齐，必须手工确认，没有捷径。
