视图用UNION ALL合并多表时，各SELECT的列数、顺序、类型必须严格一致，否则报错；字段名以首个SELECT别名为准；需为WHERE、ORDER BY字段建索引提升性能；PG支持物化视图但不自动刷新；跨库迁移前应验证各子查询独立可执行。
视图里用 UNION ALL 合并多表，但字段顺序/类型不一致就报错
SQL 视图不是“自动对齐字段”的魔法盒子。写 UNION ALL 时，各 SELECT 子句返回的列数、顺序、数据类型必须严格一致，否则建视图直接失败，常见错误是 ERROR: UNION types text and integer cannot be matched。
实操建议：
- 所有
SELECT中的字段必须按相同顺序显式写出，别依赖*—— 表结构一变就崩 - 用
CAST()或::显式转换类型，比如把id（int）和uid（text）都转成TEXT或统一用BIGINT - 字段名以第一个
SELECT的别名为准，后续子句用AS对齐命名，避免视图字段叫?column?
CREATE VIEW merged_data AS SELECT id::BIGINT AS uid, name::TEXT, 'user'::TEXT AS source FROM users UNION ALL SELECT user_id::BIGINT, full_name::TEXT, 'profile'::TEXT FROM profiles;
视图查得慢？别怪 UNION ALL，先看底层表有没有索引
视图本身不存数据，只是保存查询逻辑。如果合并的几张表没在关联字段或过滤字段上建索引，每次查视图都会全表扫描，性能雪崩。
实操建议：
- 检查每个
SELECT子句中WHERE条件涉及的字段是否都有索引，比如WHERE status = 'active'就该给status加索引 - 如果视图常按某字段排序或分页（如
ORDER BY created_at LIMIT 10），对应表的created_at字段最好有索引 - PostgreSQL 12+ 支持物化视图，但注意：它不自动刷新，
REFRESH MATERIALIZED VIEW是阻塞操作，高频更新场景慎用
MySQL 和 PostgreSQL 对视图合并的支持差异很实际
MySQL 8.0+ 支持标准 UNION ALL 视图，但不支持在视图定义里用变量或子查询作为 FROM；PostgreSQL 更宽松，允许 CTE、窗口函数甚至嵌套视图，但也更挑剔类型兼容性。
实操建议：
- 跨数据库迁移视图前，先验证
SELECT子句能否单独执行成功——这是最可靠的兼容性测试 - MySQL 中避免在视图里用
GROUP BY+UNION，容易触发ERROR 1356: View's SELECT contains a subquery in the FROM clause - PostgreSQL 若需动态表名（比如按月分表），视图做不到，得换函数或应用层拼 SQL
同步“实时性”是个假需求：视图不缓存，但也不保证事务一致性
很多人以为“用视图就等于实时”，其实不然。视图查询执行那一刻读取的是当前事务快照，如果多表数据不在同一事务里更新，查出来的可能是一张表新、一张表旧的状态，看起来像“不同步”。
实操建议：
- 真需要强一致性，得靠应用层控制：把多表更新包进同一个事务，再查视图
- 别在视图里做复杂计算（如
SUM()跨表聚合），既难优化，又放大不一致感 - 如果业务能接受秒级延迟，不如用定时任务把合并结果写入一张宽表，比反复跑视图稳定得多
字段对齐、索引覆盖、引擎差异、快照边界——这些点不手动过一遍，光靠“建个视图”解决不了同步问题。
