视图定义中跨分片join会导致查询变慢甚至失败，因分布式数据库需跨节点传输数据、协调计算，引发网络开销、超时或oom；常见报错如“cannot execute join across shards”，且单机测试通过的视图上线后易在真实负载下失效。
视图定义里 JOIN 跨分片时，查询会变慢甚至失败
分布式 SQL 数据库（如 Citus、TiDB、CockroachDB）把表按分片（shard）分散在不同节点上。如果 CREATE VIEW 语句里包含跨分片的 JOIN 或子查询，数据库无法在单个节点完成计算，必须发起分布式执行——这会触发大量网络传输、协调开销和超时风险。
常见错误现象：ERROR: cannot execute JOIN across shards（Citus）、ERROR: unsupported cross-shard query（TiDB），或查询耗时陡增、OOM 中断。
- 优先让视图只引用单一分片键上的表（例如所有表都按
tenant_id分片，且视图中WHERE tenant_id = ?条件能下推） - 避免在视图中使用
UNION ALL合并不同分片的同构表——除非底层明确支持“逻辑分片合并”且已启用 - 聚合类视图（如
GROUP BY）必须确保分组字段是分片键，否则各节点算出的局部结果无法正确归并
视图依赖的表分布在不同云区域时，权限与延迟不可控
跨云场景（比如一个视图要联查 AWS 上的 PostgreSQL 和 Azure 上的 SQL Database）本质上不属于“分布式 SQL 数据库”的原生能力范围——这类查询通常靠联邦查询（Federated Query）或外部数据源桥接实现，但视图本身不解决网络延迟、跨域认证、防火墙策略等问题。
实际影响：SELECT * FROM my_federated_view 可能因远端实例响应超时（如 30s 默认）直接报错，或返回陈旧/不一致数据（无强一致性保证）。
- 不要把跨云表直接写进视图 DDL；改用应用层组装，或用 CDC + 物化同步替代
- 若必须用联邦视图，确认底层是否支持 push-down 过滤（即把
WHERE条件发给远端执行），否则会拉全量数据到本地再过滤 - 检查远端数据库是否开放了视图所需的最小权限（如
SELECTon specific tables，而非USAGEon schema）
物化视图刷新时无法保证跨节点事务原子性
部分分布式数据库支持物化视图（如 Citus 的 MATERIALIZED VIEW），但其刷新机制通常是异步批处理，不参与全局两阶段提交（2PC）。这意味着：当底层分片数据变更时，物化视图可能短暂处于不一致状态，且无法回滚到某个一致快照点。
典型问题：报表系统读取物化视图时，看到部分分片已更新、部分未更新的中间态数据，导致金额对不上、计数重复或遗漏。
- 避免在强一致性要求场景（如财务对账）中依赖跨分片物化视图
- 改用基于时间戳或 LSN 的增量同步逻辑，在应用层控制刷新边界
- 若使用定期刷新，务必在业务低峰期执行，并配合
pg_advisory_lock类机制防止并发刷新冲突
数据本地性不是视图语法层面的限制，而是分布式执行引擎的物理约束。最容易被忽略的点是：开发时在单机库上测试通过的视图，上线到分片集群后，只要涉及跨节点关联或聚合，就大概率暴露性能与一致性问题——它不会报语法错，但会在真实负载下失效。
