MySQL 单表上亿条数据有必要考虑分表吗？目前已经 8400 万条了，感觉查询耗时也没有明显提升，就是 CPU 不查询占用也在 20%以上，不知道在干什么。如果有必要的话求推荐下 EF Core 上安全、好用的分表方法。

[edis0n0]

[lyhiving]

主要看是什么数据，读写频率是怎么样的。如果没事就没必要动

[documentzhangx66]

请先思考一个问题，为什么要分表。

[wxf666]

前排问一下，一直说的『单表超过 x 千万后，效率瞬间下降』，是因为 B+ 树层数变高（这个量级应该是 3 层变为 4 层吧），但缓存没变（比如，只缓存了前两层），导致看起来原本实际进行一次 IO ，现在需要两次，即多一倍耗时？

如果是这样，那楼主看看现在是不是已经 4 层 B+ 树了，若是就不必要分表了？（ 4 层可以容纳上百亿行了吧）

[ychost]

没必要，分表查询就很蛋疼了一般都需要分表键做路由，只要查询命中索引率高就没必要去折腾了

[thinkershare]

如果你觉得性能没问题， 就先不要管它， 等到性能出问题再去处理， 每多加一个中间层次， 都会引入很多其它的问题需要处理， 性能问题就是这样， 出了问题再去考虑优化。

[changdy]

过早的优化是万恶之源 ..

简单场景还是别分表了 后期 维护麻烦

[Maxwe11]

1 、现在跑的好好的服务，不要随便调整；
2 、但是可以自己预先做模拟，先分析业务问题，再做潜在设计，然后在测试服务器上做模拟，以防万一某一天突然出问题，可以迅速找到解决方案，毕竟业务等不得；
3 、分区分表建索引，搭缓存，各种技术方案还是由业务需求来的，如果对业务不熟悉，且对业务发展预期不清楚，确实可能会发生比如某种业务变动，导致这个提前的优化操作阻碍业务进行的情况发生，确保至少在未来新一年整体规划里，业务的变动都在考虑范围内，别到时候今天优化完了明天一调整还得回滚，好心办坏事儿还得背锅，别问我是怎么知道的。

[az467]

网络八股文说单表上亿会有性能问题，所以才要分表。

你这都没性能问题，瞎折腾好玩吗？

[agmtopy]

预估一下啥时候出问题?在你任职时间之外管它干嘛~

[zibber]

同步到 tidb

[victorc]

单表不能上亿那扯淡的，现在硬件很强劲，特别是用了 nvme 的 ssd ，比起 hd 来有几十倍的性能提升，我的业务 mysql 跑在虚拟机上，而且磁盘还是云盘！ 单表上亿也能用

分表是个大动作，要修改的地方非常多，你可以盘点一下表里面的数据，不需要得数据及时归档

[misaka19000]

没遇到瓶颈不需要折腾，有瓶颈了再去考虑

[ruiyinjinqu]

也看你写入删除的频率，分表分得不均匀也会造成问题，还有对于逻辑的优化

[LuckyLight]

如果表的字段比较多或者一行数据占用的空间比较大，按照现在的数据量，还是要考虑分表的吧

[T0m008]

不能光看数量，还要看数据结构，整个表占用空间，和未来的增长速度等等

[pavelpiero]

看看硬盘的配置 ssd 的话 上亿也很就还好

[bthulu]

别优化表了, 优化硬件最简单, SATA 机械换 NVME 的固态, 性能瞬间提升 100 倍. 你再想想你怎么优化单表能达到 100 倍以上的性能?

[zt5b79527]

我们订单表里 1.3e 数据，跑的飞快，一点问题没有（国内某公有云）

[jaylengao]

单表 1.6E 跑的飞起。引入 cache ，数据库压力很小的

[itechnology]

我的观点是，不是单表数据量达到了上亿就要分表，得看你的实际情况，大家说的要分表是因为性能已经不行了，不得不分表了，你这性能没有不行，所以我觉得暂时不用分表。