- 主题:关于多表关联查询
存储的一般套路就是数据实时性（准确性）换性能
即席发起的统计查询一般而言不等于一定需要高实时
【 在 bjhoopoe (bjhoopoe) 的大作中提到: 】
: 传统模式下，系统中有很多多表关联查询。
: 如今在互联网公司，多表关联查询基本都倾向于走数仓，但是有时效的问题。要解决时效问题，就需要建设实时数仓等支持准实时的查询。
: 传统的企业内部应用，有好多这种类似统计的功能做成了实时关联查询，有的关联多达几十张表，跨好几个库，带来很多性能问题。
: ...................
--
修改:oldwatch FROM 218.81.10.*
FROM 218.81.10.*
即席查询的话缓存命中率可以忽略不计吧
【 在 lipp ( ) 的大作中提到: 】
: 索引
: SQL语句优化
: 冗余字段
: ...................
--
FROM 218.81.15.*
这不就是传说中的实体化视图
【 在 canper (洗衣粉) 的大作中提到: 】
: 要啥链接，最简单的就是生成一个单表包含了多个表join的结果，专门用来做查询，生成可以做到很实时，join的多个表里任何一个表可能修改的时候刷新生成的表。
: 然后在这个表上做索引，做分区，可以做成很高性能
--
修改:oldwatch FROM 218.79.250.*
FROM 218.79.250.*
噢，还好，我们那时是OLAP场景……
【 在 liuxueshen ( rock) 的大作中提到: 】
: 我遇到过DB2的更新慢，并且拖慢原表插入速度。
: 多任务插入更新同一张表偶尔发生互锁时发现的，
: 如果不用物化视图就没这情况。
: ...................
--
FROM 218.79.250.*