1
Raymon111111 2019-01-07 19:33:57 +08:00
比如读大量数据到 buffer pool 中把要用的热点数据挤出去了, 导致其它查询变慢
|
2
jrient 2019-01-07 20:20:30 +08:00
为什么不考虑解决 2 亿数据的问题
|
3
likuku 2019-01-07 20:26:16 +08:00 via iPhone
数据分析用 db 和业务用 db 分开在不同物理机器上,不同需求求得不同的机器配置来满足,至少先这样。
|
4
zzzzzzZ 2019-01-07 20:28:16 +08:00 via Android
9012 年了居然还有 table 能有两亿数据的吗
|
5
t6attack 2019-01-07 20:30:36 +08:00 1
就算它不崩,也查不完啊。这种实际扫描全表的次数,不是做加法,而是做乘法。
关键词:mysql join 成本 |
7
chenxytw 2019-01-07 20:44:21 +08:00
崩掉是指..... mysqld 进程 crash 么?
|
8
byteli 2019-01-07 23:03:25 +08:00 via Android
原因各种,但都离不开数据量大&机器配置捉急这个根源。建议 explain 看看执行计划,到底是哪一步量太大,想办法分步查询,或者提前 limit 大小。
|
10
Linxing 2019-01-08 10:18:44 +08:00 via iPhone
拖慢其它查询就已经够呛了
|
11
Rush9999 2019-01-08 10:36:30 +08:00
有可能会遍历整表,导致临时文件巨大,然后就。。。。。。。。。。
|
12
glacer 2019-01-08 10:46:37 +08:00 1
首先「两亿数据的 table 做关联查询可能会崩掉 mysql 」是必现?是楼主复现过还是「据说」?
|
13
hq136234303 2019-01-08 10:51:39 +08:00
应该是 CPU 100%了吧。
|
14
snnn 2019-01-08 11:20:30 +08:00 via Android
2 亿乘以 2 亿等于多少?计算机什么时候也处理不了这么大级别的数据
|
15
JamesMackerel 2019-01-08 12:52:51 +08:00 via iPhone
一般可以用子查询选出两个比较小的表再 join,涉及多表的 join 可以放到业务层搞,方便扩容。
|
16
troywinter 2019-01-08 16:38:20 +08:00
正常的业务需求不应该有这种操作,至少在 OLTP 系统中不应该有这种操作,如果是数据分析需求应该放到 OLAP 中做,不应该在在线数据库做这种事情。 至于楼上各位说的分表之后还有上亿条数据的,我表示 MySQL 在不明显影响性能的前提下的极限应该达不到亿级,千万级差不多。
|