视图在分布式数据库中变慢的本质是跨节点数据搬运过多。当JOIN字段非分片键、分片策略不一致、含函数表达式或外层ORDER BY/LIMIT时，协调节点需拉取大量中间结果，导致网络与CPU瓶颈。
视图在分布式数据库里慢，本质是跨节点数据搬运太多
分布式数据库（如TiDB、CockroachDB、OceanBase）执行视图时，不会把整个视图逻辑“推”到单个节点上计算，而是按分片规则把底层表的查询拆开，再把中间结果拉到协调节点（coordinator node）做JOIN、聚合或排序。一旦视图定义里含多表JOIN、子查询或ORDER BY，就极易触发大量跨网络的数据传输——这才是性能崩塌的主因，不是视图语法本身有问题。
哪些JOIN会强制拉全量数据？
当JOIN字段不是分片键，或两边分片策略不一致时，协调节点必须把至少一边的表（甚至全表）从多个节点汇总过来才能匹配。常见踩坑点：
-
ON orders.user_id = users.id，但orders按order_id分片、users按id分片 → 两边无法对齐，users表大概率被全量拉取 - 视图里用
LEFT JOIN且右表无WHERE过滤 → 协调节点不敢裁剪，倾向拉全量 - JOIN条件含函数或表达式，如
ON SUBSTRING(order_no, 1, 8) = users.code→ 分片键失效，退化为广播或重分布 - 外层查询对视图加
ORDER BY created_at LIMIT 10→ 所有分片先各自排序，再把全部结果拉到协调节点二次排序
怎么让视图避开跨节点拉数据？
核心思路是：让JOIN能下推到分片内部完成，避免协调节点成为瓶颈。实操建议：
- 确保所有JOIN字段都是对应表的分片键，且类型、长度、字符集完全一致（隐式转换会导致下推失败）
- 视图中禁用
SELECT *，只选需要字段；尤其避免SELECT大文本字段（如description、json_data），它们会显著放大网络传输量 - 把高频使用的过滤条件（如
WHERE tenant_id = ?）直接写进视图定义，而不是靠外层加——很多分布式库不支持谓词下推到嵌套视图 - 聚合类视图优先用
GROUP BY+ 分片键（如GROUP BY shop_id），让每个分片独立算局部聚合，再合并 - 确认数据库是否支持“局部视图”（如TiDB的
/*+ READ_FROM_STORAGE(TIKV[t1]) */提示），必要时手动指定数据源位置
为什么EXPLAIN看不出来跨节点代价？
多数分布式数据库的EXPLAIN只展示逻辑计划，不暴露物理调度细节。真正要定位数据搬运问题，得看：
- 执行后的
EXPLAIN ANALYZE输出里是否有Exchange、HashJoin (Broadcast)、MergeJoin (Remote)等字样 - 监控面板中“Network In/Out”指标是否远高于单机模式（比如一次查询拉取2GB数据）
- 协调节点CPU和网络带宽是否持续打满，而工作节点空闲
- 日志中是否频繁出现
coprocessor task timeout或region unavailable（说明跨地域拉取失败重试）
最隐蔽的问题是：视图看起来只查10行，但底层JOIN迫使每个分片都扫描百万行再上传——这个代价在EXPLAIN里常被掩盖成“小结果集”，实际网络IO已爆炸。
