不能直接用 union all 合并归档表和实时表，因为二者存在列数、字段顺序、数据类型不一致，以及归档表多出元数据列（如 archived_at）、时间字段时区/精度/默认值语义不同等隐性不兼容问题，导致建视图失败或结果错乱。
为什么不能直接用 UNION ALL 合并归档表和实时表？
因为字段顺序、类型不一致，或归档表里多了 archive_date 而实时表没有，UNION ALL 会报错。MySQL 和 PostgreSQL 都要求列数相同、对应列类型兼容（如 VARCHAR 和 TEXT 在某些版本不自动隐式转换）。更隐蔽的问题是：实时表有 GENERATED COLUMN 或默认值表达式，而归档表是静态数据，直接拼接会导致语义错乱。
- 先用
DESCRIBE table_name或\d table_name查两表的列名、类型、是否允许 NULL - 归档表中多出的元数据列（如
archived_at）必须在实时表查询中补NULL AS archived_at - 若某列为
TIMESTAMP类型但实时表用CURRENT_TIMESTAMP默认，归档表需显式 cast：CAST('1970-01-01' AS TIMESTAMP) AS created_at
PostgreSQL 中创建视图时如何处理分区键与约束排除？
如果归档表按年分区（如 orders_2022, orders_2023），而实时表是 orders_current，直接 UNION ALL 会让查询无法利用分区剪枝。PostgreSQL 11+ 支持在视图定义中加入 WHERE 条件提示优化器，但视图本身不存储执行计划——真正起作用的是后续查询是否能下推谓词。
- 给每个子表加明确的分区标识列，例如归档表统一加
'archive'::TEXT AS source_type，实时表用'live'::TEXT - 在视图里不要写
WHERE created_at > '2024-01-01'—— 这会固化过滤逻辑，应留给上层查询自由下推 - 确保各子表的
created_at列都有索引，否则即使下推了条件，扫描效率仍低
MySQL 视图合并时遇到 View's SELECT contains a subquery in the FROM clause 错误怎么办？
这是 MySQL 的限制：视图定义中不能嵌套子查询作为 FROM 表源。如果你试图把归档表做 (SELECT * FROM orders_archive WHERE status = 'done') AS a 再 UNION ALL，就会触发该错误。
- 改用物化中间表临时替代：先建
CREATE TABLE tmp_orders_archive AS SELECT * FROM orders_archive WHERE status = 'done'，再在视图中引用它（注意定期清理） - 或者把过滤逻辑移到上层查询：视图只做裸合并，让业务 SQL 自己加
WHERE source_type = 'live' AND status = 'done' - MySQL 8.0.23+ 支持 CTE，但视图仍不支持 CTE，所以
WITH不能出现在视图定义中
视图性能差、查询超时，是不是该加索引？
视图本身不存数据，也不支持直接建索引。所谓“给视图加索引”其实是给底层基表建合适的索引，并确保查询能命中。常见误区是只在实时表建了索引，却忽略归档表的等价索引。
- 检查执行计划：
EXPLAIN FORMAT=TREE SELECT * FROM merged_orders_view WHERE user_id = 123，确认是否对每个子表都用了索引扫描 - 归档表若为 MyISAM，记得转成 InnoDB 并加联合索引，例如
(user_id, created_at) - 如果视图里用了
ORDER BY或LIMIT，MySQL 可能强制临时表排序，此时应在上层查询控制分页，而非写死在视图里
实际中最容易被忽略的是时间字段的时区一致性：归档表可能用 UTC 存储，实时表却用本地时区插入，合并后 ORDER BY created_at DESC 会错乱。这个细节不会报错，但结果不可信。
