首先和你说这种问题是无解的
只能想办法缓解，在数据库内部想办法就是基本没办法。
大表join加上跨库这玩意就不可能快。
一般的绕过办法是数据仓库上宽表，就是干脆把join的结果物理存储下来。当然存储的方式可以做很多优化。

【 在 bjhoopoe (bjhoopoe) 的大作中提到: 】
: 标  题: 关于多表关联查询
: 发信站: 水木社区 (Wed Feb 17 15:14:56 2021), 站内
:
: 传统模式下，系统中有很多多表关联查询。
:
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
:
: 传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
:
: 请问这种场景大家一般怎么解决？
:
: --
:
: ※ 来源:·水木社区 http://www.newsmth.net·[FROM: 221.223.46.*]
--
FROM 106.39.148.*

我另一个回帖有说。



【 在 varchar (varchar) 的大作中提到: 】
: 标  题: Re: 关于多表关联查询
: 发信站: 水木社区 (Mon Feb 22 22:36:45 2021), 站内
:
: 虽然无解，没法从根上解决，但是总有解决能尽量提高性能吧
: 【 在 Knightmare 的大作中提到: 】
: :  
: : 这问题是无解的。  
: : 不知道无解的问题算不算好。  
: :
: :
:
: 发自「今日水木 on iOS」
: --
:
: ※ 来源:·水木社区 http://www.newsmth.net·[FROM: 111.30.201.*]
--
FROM 106.39.148.*

re  
  
【 在 Knightmare (梦醒时分) 的大作中提到: 】
:  首先和你说这种问题是无解的
:  只能想办法缓解，在数据库内部想办法就是基本没办法。
:  大表join加上跨库这玩意就不可能快。
:  一般的绕过办法是数据仓库上宽表，就是干脆把join的结果物理存储下来。当然存储的方式可以做很多优化。
--
FROM 124.64.17.*

跨库大查询直接dblink join的我遇到过临时表写爆了的
我自己干活要大跨库都是土办法先把数据集中到一头，占点空间就空间把。
【 在 SankHeart (披发头陀⊥) 的大作中提到: 】
: 跨库是大问题，可以考虑用goldengate这类准实时工具先把数据集中到一个库里
--
FROM 115.204.136.*

这不就是传说中的实体化视图

【 在 canper (洗衣粉) 的大作中提到: 】
:  要啥链接，最简单的就是生成一个单表包含了多个表join的结果，专门用来做查询，生成可以做到很实时，join的多个表里任何一个表可能修改的时候刷新生成的表。
:  然后在这个表上做索引，做分区，可以做成很高性能
--
修改:oldwatch FROM 218.79.250.*
FROM 218.79.250.*