SQL Server中UNION ALL分片视图数据缺失，因各分支缺少唯一分片条件；MySQL视图无法下推WHERE条件致全表扫描；跨库视图需联邦引擎或应用层聚合，原生不支持；建议优先使用数据库原生分区表。
SQL Server 里用 UNION ALL 拼接分片表时，为什么查询结果少了数据？
因为视图里漏写了 WHERE 条件，或者各分片表的过滤逻辑不一致。SQL Server 视图本身不强制校验底层表数据是否重叠或遗漏，UNION ALL 只是机械拼接——它不会帮你检查某条订单该去 orders_2023 还是 orders_2024。
实操建议：
- 每个
SELECT分支必须显式带上能唯一确定分片归属的条件，比如WHERE order_date >= '2023-01-01' AND order_date - 避免用
UNION（带去重），它会触发排序和去重开销，对分片视图毫无意义，还可能掩盖重复数据问题 - 在视图定义末尾加个注释，标明分片键和边界，例如：
-- sharding key: order_date, ranges: [2023), [2024), [2025)
PostgreSQL 中定义分片视图，CHECK OPTION 能不能防止误插入？
不能。CHECK OPTION 只对通过视图执行的 INSERT/UPDATE 生效，且仅检查当前视图定义里的约束；它不感知分片逻辑，也不阻止你往错的底层表写数据。
实操建议：
- 分片视图默认只读，别给
INSERT权限；真要写，走专用写入函数或应用层路由 - 如果硬要用视图支持写入，得配合规则（
CREATE RULE）或 instead-of 触发器，但 PostgreSQL 12+ 更推荐用分区表（PARTITION BY RANGE）替代手工视图分片 -
CHECK CONSTRAINT要加在每个分片表上，而不是视图上，例如在orders_2024表加CHECK (order_date >= '2024-01-01')
MySQL 分片视图性能差，EXPLAIN 显示全表扫描所有分片？
MySQL 视图没有“条件下推”优化能力，即使你在查询视图时加了 WHERE order_id = 123，优化器也大概率无法把这条件自动下推到每个 SELECT 分支里，于是每个分片都扫一遍。
实操建议：
- 别依赖视图做高频点查；改用应用层根据分片键直接访问目标表，比如查
order_id=123就算出落在orders_shard2，然后直连查 - 如果非要用视图，把最常用的过滤字段（如
tenant_id、shard_key）作为视图参数模拟（靠应用拼 SQL），而不是指望优化器智能下推 - 确认每个分片表都有对应索引：不是只在视图上建索引（视图不能建索引），而是在每个底层表的分片键上建好索引
跨库分片视图怎么写？比如把 MySQL 和 PostgreSQL 的订单表合并成一个视图
原生 SQL 标准不支持跨异构数据库的视图。所谓“跨库”，实际只能靠中间层实现——数据库自身视图做不到。
实操建议：
- 放弃用单个
CREATE VIEW实现，那是伪需求；要么用联邦查询引擎（如postgres_fdw把 MySQL 表当外部表挂进 PG，再建视图），要么用应用层聚合 - 用
postgres_fdw时注意：MySQL 表需开启binlog_row_image=FULL才支持某些操作；且远程表的WHERE条件不一定能下推，容易拉全量 - 如果只是报表类低频查询，用 ETL 工具定时同步到统一数仓更稳，比实时跨库视图靠谱得多
分片视图本质是手动模拟分区表，而现代数据库早把这事封装好了。你花半天调通一个带五个 UNION ALL 的视图，不如花二十分钟把表改成 PostgreSQL 的原生分区表——它自动下推条件、自动剪枝、还能在线迁移。手写视图最容易被忽略的，是它根本没事务边界、没一致性保障、也没办法原子性地增删一个分片。
