视图含join会触发跨节点数据搬运。因分布式数据库无法将join逻辑下推至单节点执行，需在协调节点拉取多节点数据合并，若关联字段非分片键或分片策略不一致，将导致全表扫描与网络开销激增。
视图定义里含JOIN就等于主动触发跨节点数据搬运
分布式数据库（如TiDB、OceanBase）执行视图时，不会把整个逻辑“推下去”在单个节点算完，而是把底层表的查询按分片规则拆开，再把中间结果拉到协调节点做JOIN、排序或聚合。一旦视图里写了JOIN，且关联字段不是分片键，或者两边分片策略不一致，协调节点就得从多个节点拉数据——这不是慢，是直接放大网络开销。
常见踩坑点：
-
ON orders.user_id = users.id，但orders按order_id分片、users按id分片 → 两边无法对齐，users表大概率被全量拉取 -
LEFT JOIN右表没加WHERE过滤 → 协调节点不敢裁剪，倾向拉全量 -
ON SUBSTRING(order_no, 1, 8) = users.code→ 分片键失效，退化为广播或重分布
ORDER BY + LIMIT在视图外层会强制二次归并
视图本身不存数据，只是保存SQL逻辑。如果视图定义里没写排序，而外层查询加了ORDER BY created_at LIMIT 10，协调节点就得先把所有分片的结果都拉回来，再全局排序取前10——哪怕每个分片只返回10行，100个分片也要传1000行；如果每行带TEXT或JSON字段，传输量会指数级上涨。
实操建议：
- 把高频排序字段（如
created_at）和分片键一起建复合索引，并确保该字段在视图中被显式选中 - 避免在视图外层加
LIMIT，改用分片内局部限流+协调节点合并（如先各取10，再全局取10） - 禁用
SELECT *，只选真正需要的字段，尤其避开大文本字段
UNION ALL拼分片表时类型不一致直接报错
有人想绕过跨分片JOIN，手动写SELECT * FROM t_shard_01 UNION ALL SELECT * FROM t_shard_02建视图。这看似可行，但极易失败：
- 字段顺序或数量不一致 → 报错
column count mismatch - 同名字段类型不同（如
DECIMAL(10,2)vsDECIMAL(12,2)）→ 报错incompatible types in UNION ALL - 字符串字段字符集或排序规则不统一 → 合并失败，尤其在MySQL代理层（如ProxySQL）下更敏感
真正能跑通的做法是：每个SELECT子句必须显式写出字段名，且字段数、顺序、类型（含精度、字符集、collation）完全一致。
视图里调用函数会让执行计划彻底失控
视图中出现NOW()、USER()、自定义函数（如my_encrypt()），会导致两个问题：
- 函数只在当前节点加载 → 查询路由到没注册该函数的节点时，直接报
FUNCTION does not exist - 时间类函数因节点时钟偏差，同一视图多次查询可能返回不一致结果
- 隐式类型转换（如
WHERE user_id = CAST(id AS CHAR)）让分片路由失效，触发全库广播
关键判断：只要视图定义里出现任何函数调用，就要默认它无法下推，所有计算都会回到协调节点完成。
最常被忽略的一点：视图不是性能优化手段，而是逻辑封装工具。在分布式环境下，它甚至会掩盖真实的数据搬运路径——你以为只是“换个名字查”，实际已在后台拉了几十MB数据。
