- 主题:关于多表关联查询
传统模式下，系统中有很多多表关联查询。
如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
请问这种场景大家一般怎么解决？
--
FROM 221.223.46.*
同问。
实时性问题还好，内部系统稍微延迟一般也没问题
【 在 bjhoopoe (bjhoopoe) 的大作中提到: 】
: 传统模式下，系统中有很多多表关联查询。
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
: 传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
: ...................
--
FROM 61.145.150.*
1数据库做成读写分离高可用
2拆分复杂的查询入到中间表，比如一个库一个中间表，再这些中间表做关联
【 在 bjhoopoe 的大作中提到: 】
: 传统模式下，系统中有很多多表关联查询。
:
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
: ....................
- 来自「最水木 for iPhone X」
--
FROM 101.64.80.*
和读写分离关系其实不大。
主要企业应用传统的思路就是 多表关联查询，很多类似统计报表的需求做成了普通的即时查询。
比较疼痛的是表关联的太多了。 不知道大家都是怎么改进优化这种应用场景的？
【 在 wei167 的大作中提到: 】
: 1数据库做成读写分离高可用
: 2拆分复杂的查询入到中间表，比如一个库一个中间表，再这些中间表做关联
: - 来自「最水木 for iPhone X」
--
FROM 221.223.46.*
存储的一般套路就是数据实时性（准确性）换性能
即席发起的统计查询一般而言不等于一定需要高实时
【 在 bjhoopoe (bjhoopoe) 的大作中提到: 】
: 传统模式下，系统中有很多多表关联查询。
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
: 传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
: ...................
--
修改:oldwatch FROM 218.81.10.*
FROM 218.81.10.*
【 在 bjhoopoe 的大作中提到: 】
: 传统模式下，系统中有很多多表关联查询。
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
: 传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
: ...................
如果关联的表有很多静态表，可以设法放内存。
--
FROM 221.221.49.*
好问题，顶
--
FROM 111.30.201.*
索引
SQL语句优化
冗余字段
独立的统计表，定时自动统计或者用流引擎触发统计
redis之流的缓存
【 在 bjhoopoe (bjhoopoe) 的大作中提到: 】
: 和读写分离关系其实不大。
: 主要企业应用传统的思路就是 多表关联查询，很多类似统计报表的需求做成了普通的即时查询。
: 比较疼痛的是表关联的太多了。 不知道大家都是怎么改进优化这种应用场景的？
--
修改:lipp FROM 123.103.9.*
FROM 123.103.9.*
即席查询的话缓存命中率可以忽略不计吧
【 在 lipp ( ) 的大作中提到: 】
: 索引
: SQL语句优化
: 冗余字段
: ...................
--
FROM 218.81.15.*
这问题是无解的。
不知道无解的问题算不算好。
【 在 varchar (varchar) 的大作中提到: 】
: 标 题: Re: 关于多表关联查询
: 发信站: 水木社区 (Fri Feb 19 14:19:19 2021), 站内
:
: 好问题，顶
: --
:
: ※ 来源:·水木社区
http://www.newsmth.net·[FROM: 111.30.201.*]
--
FROM 106.39.148.*