请教：两亿数据的 table 做关联查询可能会崩掉 mysql，崩掉的服务器表现是什么，原因又是什么。因为我是小白，懂得不多，冒昧提问。

比如读大量数据到 buffer pool 中把要用的热点数据挤出去了, 导致其它查询变慢

为什么不考虑解决 2 亿数据的问题

数据分析用 db 和业务用 db 分开在不同物理机器上，不同需求求得不同的机器配置来满足，至少先这样。

9012 年了居然还有 table 能有两亿数据的吗

就算它不崩，也查不完啊。这种实际扫描全表的次数，不是做加法，而是做乘法。
关键词：mysql join 成本

@zzzzzzZ 两亿并不是很大的量，真正需要分表的业务，分表之后都是单表亿级的

崩掉是指..... mysqld 进程 crash 么?

原因各种，但都离不开数据量大&机器配置捉急这个根源。建议 explain 看看执行计划，到底是哪一步量太大，想办法分步查询，或者提前 limit 大小。

@sagaxu
哇！分完表之后还有上亿条数据的单表啊？这么厉害的吗？

拖慢其它查询就已经够呛了

有可能会遍历整表，导致临时文件巨大，然后就。。。。。。。。。。

首先「两亿数据的 table 做关联查询可能会崩掉 mysql 」是必现？是楼主复现过还是「据说」？

应该是 CPU 100%了吧。

2 亿乘以 2 亿等于多少？计算机什么时候也处理不了这么大级别的数据

一般可以用子查询选出两个比较小的表再 join，涉及多表的 join 可以放到业务层搞，方便扩容。

正常的业务需求不应该有这种操作，至少在 OLTP 系统中不应该有这种操作，如果是数据分析需求应该放到 OLAP 中做，不应该在在线数据库做这种事情。 至于楼上各位说的分表之后还有上亿条数据的，我表示 MySQL 在不明显影响性能的前提下的极限应该达不到亿级，千万级差不多。