create view 无法自动合并分表，必须手动用 union all 显式拼接各分表，且需严格保证字段数量、顺序、类型、字符集一致，显式列出所有字段并补全缺列，where 条件不自动下推导致全表扫描，视图仅简化查询入口，不解决写入路由、分区裁剪等核心问题。
CREATE VIEW 本身不自动合并分表，必须手动写 UNION ALL 显式拼接——没有“自动”这回事，所谓“逻辑合并”只是封装查询逻辑，底层仍需你一条条列出每个分表。
字段对齐和类型兼容是建视图的第一道坎
建视图失败最常见的原因是列数、顺序、类型三者没对齐。哪怕两张表都叫 id，一个定义为 INT，另一个是 VARCHAR(20)，MySQL 或 PostgreSQL 都会直接报错，比如：ERROR: UNION types integer and text cannot be matched。
- 必须显式写出所有字段，禁用
*—— 某张分表后续加列，视图就崩 - 用
::（PostgreSQL）或CAST(... AS ...)（MySQL/SQL Server）强制统一类型，例如id::BIGINT、status::TEXT - 缺列必须补位：
NULL::TEXT AS remark，不能只写NULL（类型不明确） - 字符集也要一致：一张表用
utf8mb4_unicode_ci，另一张用utf8mb4_general_ci，MySQL 会拒绝创建视图
WHERE 条件不下推 = 全表扫描所有分表
视图里写 SELECT * FROM orders_view WHERE order_date >= '2024-01-01' 看似简洁，但优化器大概率不会把条件下推到每个 UNION ALL 分支，结果就是每张分表都全扫一遍。
- 正确做法：每个
SELECT子句都带独立WHERE，且确保字段类型完全一致（DATE和DATETIME不兼容） - 分区键字段（如
order_date）必须在每张分表上建索引，否则某一分支仍走全表扫描 - 建好视图后，用
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）确认是否每支都命中索引
别指望视图能替代原生分区或分表路由
视图只是查询入口的包装，不解决写入分发、数据生命周期管理、跨分表 JOIN 或事务一致性问题。它解决的唯一问题是“让应用代码不用感知分表存在”。
- 写入仍需业务层路由到具体分表，视图不可 INSERT/UPDATE（除非是可更新视图，但
UNION ALL视图基本不可更新） - 无法利用数据库原生分区裁剪（如 PostgreSQL 的
PARTITION BY RANGE），优化器能力受限 - 分表数量超过 10–15 张时，执行计划变复杂，硬解析开销上升，性能劣化明显
- 如果已有按月命名的手动分表（如
orders_202401、orders_202402），用脚本生成视图 DDL 是最稳妥的维护方式
真正麻烦的不是写视图，而是保证所有分表结构长期一致、索引始终有效、统计信息及时更新——这些细节一松懈，视图就从便利工具变成性能黑洞。
