视图不能替代分库分表，仅能统一查询入口；它不解决物理拆分问题，也不支持自动路由或跨库下推谓词，本质是逻辑封装，适用于稳定低频分片场景。
视图不能替代分库分表，但能统一查询入口
SQL 视图本身不解决物理层面的分表分库问题，它只是对查询逻辑的一层封装。你无法靠 CREATE VIEW 把数据自动拆到不同库或不同表里，也不能让 MySQL 或 PostgreSQL 自动路由到多个物理节点。它真正的作用是：让应用代码不用感知底层是单表、联合表、跨库表（需 FEDERATED / postgres_fdw）还是 UNION ALL 拼接的分片表。
用 UNION ALL 在单库内模拟水平分表查询
当分表仍在同一数据库内（比如按时间分表：orders_202401、orders_202402），可用视图聚合查询：
CREATE VIEW orders_all AS SELECT '202401' AS month, order_id, amount, created_at FROM orders_202401 UNION ALL SELECT '202402' AS month, order_id, amount, created_at FROM orders_202402 UNION ALL SELECT '202403' AS month, order_id, amount, created_at FROM orders_202403;
注意点：
-
UNION ALL比UNION快，避免去重开销；务必确认各子查询字段顺序、类型、数量完全一致 - MySQL 8.0+ 支持在视图中使用参数化注释（如
/*+ SHARDING_KEY(order_id) */），但不改变执行计划——真要下推条件，得靠查询时手动加WHERE month = '202402' - 如果某张分表缺失或字段变更，视图会直接报错
ERROR 1356: View 'db.orders_all' references invalid table(s)
跨库查询必须依赖外部扩展，视图只是“壳”
原生 MySQL 不支持跨库字段对齐的视图（比如查 shard1.orders 和 shard2.orders）。要实现，得先启用 FEDERATED 引擎或使用 postgres_fdw（PostgreSQL）把远端表映射成本地表，再建视图：
以 MySQL 为例：
CREATE SERVER shard2 FOREIGN DATA WRAPPER mysql OPTIONS (HOST '10.0.1.2', DATABASE 'shop', USER 'reader', PASSWORD '***'); <p>CREATE TABLE orders_shard2 ( order_id BIGINT, amount DECIMAL(10,2), created_at DATETIME ) ENGINE=FEDERATED CONNECTION='shard2/orders';</p>
然后才能：
CREATE VIEW orders_global AS SELECT 'shard1' AS source, * FROM shop.orders UNION ALL SELECT 'shard2' AS source, * FROM orders_shard2;
风险点：
-
FEDERATED表不支持事务一致性，SELECT可能读到远端瞬时状态 - 没有下推谓词能力——
SELECT * FROM orders_global WHERE order_id = 123会拉取所有分片全量数据再过滤 - MySQL 8.0 默认禁用
FEDERATED，需启动时加--federated参数
别把视图当性能优化手段，它可能让慢查询更慢
视图本质是保存的 SELECT 语句，每次查询都会展开执行。如果底层是几十个分表 UNION ALL，又没加有效 WHERE 条件，就会触发全表扫描叠加。
实际建议：
- 只对固定、稳定、低频变化的分片结构建视图；动态分片（如按用户 ID 哈希）不适合用视图硬编码
- 应用层仍需承担路由逻辑：先算出应查哪张物理表（如
orders_%d% (user_id % 16)），再发查询；视图只用于管理后台这类无需强路由的场景 - PostgreSQL 的物化视图（
MATERIALIZED VIEW）可缓存结果，但需手动REFRESH，不适用于实时性要求高的分库分表场景
真正需要透明分库分表，得用 ShardingSphere、Vitess 或业务层分片框架——视图只是胶水，不是引擎。
