MySQL 单表上亿条数据有必要考虑分表吗？目前已经 8400 万条了，感觉查询耗时也没有明显提升，就是 CPU 不查询占用也在 20%以上，不知道在干什么。如果有必要的话求推荐下 EF Core 上安全、好用的分表方法。
edis0n0 · 2022-09-25 12:53:35 +08:00 · 6341 次点击这是一个创建于 801 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
lyhiving 2022-09-25 13:06:04 +08:00
主要看是什么数据，读写频率是怎么样的。如果没事就没必要动
|
 |
2
documentzhangx66 2022-09-25 13:09:24 +08:00
请先思考一个问题，为什么要分表。
|
 |
3
wxf666 2022-09-25 13:11:58 +08:00
前排问一下，一直说的『单表超过 x 千万后，效率瞬间下降』，是因为 B+ 树层数变高（这个量级应该是 3 层变为 4 层吧），但缓存没变（比如，只缓存了前两层），导致看起来原本实际进行一次 IO ，现在需要两次，即多一倍耗时？
如果是这样，那楼主看看现在是不是已经 4 层 B+ 树了，若是就不必要分表了？（ 4 层可以容纳上百亿行了吧） |
 |
4
ychost 2022-09-25 14:32:05 +08:00
没必要，分表查询就很蛋疼了一般都需要分表键做路由，只要查询命中索引率高就没必要去折腾了
|
 |
5
thinkershare 2022-09-25 15:59:17 +08:00
如果你觉得性能没问题， 就先不要管它， 等到性能出问题再去处理， 每多加一个中间层次， 都会引入很多其它的问题需要处理， 性能问题就是这样， 出了问题再去考虑优化。
|
 |
6
changdy 2022-09-25 16:10:44 +08:00
过早的优化是万恶之源 ..
简单场景还是别分表了 后期 维护麻烦 |
 |
7
Maxwe11 2022-09-25 18:13:42 +08:00
1 、现在跑的好好的服务，不要随便调整；
2 、但是可以自己预先做模拟，先分析业务问题，再做潜在设计，然后在测试服务器上做模拟，以防万一某一天突然出问题，可以迅速找到解决方案，毕竟业务等不得； 3 、分区分表建索引，搭缓存，各种技术方案还是由业务需求来的，如果对业务不熟悉，且对业务发展预期不清楚，确实可能会发生比如某种业务变动，导致这个提前的优化操作阻碍业务进行的情况发生，确保至少在未来新一年整体规划里，业务的变动都在考虑范围内，别到时候今天优化完了明天一调整还得回滚，好心办坏事儿还得背锅，别问我是怎么知道的。 |
 |
8
az467 2022-09-25 18:38:04 +08:00
网络八股文说单表上亿会有性能问题，所以才要分表。
你这都没性能问题，瞎折腾好玩吗？ |
 |
9
agmtopy 2022-09-25 22:02:45 +08:00
预估一下啥时候出问题?在你任职时间之外管它干嘛~
|
 |
10
zibber 2022-09-25 22:06:09 +08:00
同步到 tidb
|
 |
11
victorc 2022-09-25 22:23:41 +08:00
单表不能上亿那扯淡的，现在硬件很强劲，特别是用了 nvme 的 ssd ，比起 hd 来有几十倍的性能提升，我的业务 mysql 跑在虚拟机上，而且磁盘还是云盘！ 单表上亿也能用
分表是个大动作，要修改的地方非常多，你可以盘点一下表里面的数据，不需要得数据及时归档 |
 |
12
misaka19000 2022-09-25 22:30:59 +08:00
没遇到瓶颈不需要折腾，有瓶颈了再去考虑
|
 |
13
ruiyinjinqu 2022-09-25 23:04:57 +08:00
也看你写入删除的频率，分表分得不均匀也会造成问题，还有对于逻辑的优化
|
 |
14
LuckyLight 2022-09-26 00:07:05 +08:00
如果表的字段比较多或者一行数据占用的空间比较大，按照现在的数据量，还是要考虑分表的吧
|
 |
15
T0m008 2022-09-26 02:34:14 +08:00
不能光看数量，还要看数据结构，整个表占用空间，和未来的增长速度等等
|
 |
16
pavelpiero 2022-09-26 08:41:38 +08:00
看看硬盘的配置 ssd 的话 上亿也很就还好
|
 |
17
bthulu 2022-09-26 09:15:42 +08:00
别优化表了, 优化硬件最简单, SATA 机械换 NVME 的固态, 性能瞬间提升 100 倍. 你再想想你怎么优化单表能达到 100 倍以上的性能?
|
 |
18
zt5b79527 2022-09-26 09:21:06 +08:00
我们订单表里 1.3e 数据，跑的飞快，一点问题没有（国内某公有云）
|
 |
19
jaylengao 2022-09-26 09:32:40 +08:00  1
单表 1.6E 跑的飞起。引入 cache ，数据库压力很小的
|
 |
20
itechnology 2022-09-26 09:41:08 +08:00
我的观点是，不是单表数据量达到了上亿就要分表，得看你的实际情况，大家说的要分表是因为性能已经不行了，不得不分表了，你这性能没有不行，所以我觉得暂时不用分表。
|
 |
21
INCerry 2022-09-26 09:45:06 +08:00
如上面所说，硬件 OK 的情况下单表上亿问题不大，后面如果数据量更大，可以考虑下面的分库分表中间件。
https://github.com/dotnetcore/sharding-core |
 |
22
ipwx 2022-09-26 10:02:01 +08:00
可以不动生产环境，但是可以开个模拟环境测试性能嘛。
|
 |
23
encro 2022-09-26 10:24:47 +08:00
看你记录类型和查询方式，可以考虑冷热分离方式。
|
 |
24
leafre 2022-09-26 11:08:11 +08:00
会导致业务逻辑复杂度增加，不轻易使用分库分表
不是达到多少数量量就一定要分库分表，主要看性能，性能不行了，没办法从其他方面优化了，万不得已可以考虑分库分表。 |
|
25
leafre 2022-09-26 11:10:22 +08:00
比如十亿数据表，单字段维度的过滤查询结果，查询时间 100ms 左右，根本不用考虑分表
|
 |
26
wdwwtzy 2022-09-26 13:03:12 +08:00
听说 sqlserver 的优化更好，单表几亿几十亿都没问题？
有人确认过吗？ |
 |
27
dcsuibian 2022-09-26 13:15:20 +08:00
没有性能问题就先别管它
我之前有一个历史数据表，里面就是时间戳+关联 id+值，主要就是查询某个时间点的状态，建了索引（没建肯定慢的要死） 测试时放了 8 亿条（或者是 4 亿条，记不清了），然后查了 1000 次，总共就花了 1 秒多，感觉够用了就没改 |
 |
28
sadfQED2 2022-09-26 13:49:38 +08:00 via Android
我前司，一张评论表 20 亿+数量，依然正常使用，uid 查询 10ms 以内
|
 |
30
cubecube 2022-09-26 13:59:19 +08:00
分表没啥用，除非你单机 cpu 扛不住的时候，分库顺便分表。
|
 |
31
leegradyllljjjj 2022-09-26 14:02:58 +08:00
现在的人都喜欢瞎坤巴折腾，我们组就有个人就喜欢看见别入弄点啥都想拿来折腾一下，完全是闲着没事儿为了折腾而折腾，到时候出点线上问题你还得为他擦屁股背锅
|
 |
32
dog82 2022-09-26 14:35:23 +08:00
要看表里的数据怎么用，如果只是按 id 查询就不要分
|
 |
33
nekoneko 2022-09-26 17:45:34 +08:00
分表会搞得很麻烦, 系统不大的话不如分区, 跟分表是一样的效果.
另外如果没有必要, 就不要分了 |
 |
34
ytmsdy 2022-09-26 19:33:04 +08:00
只要能跑，用户能接受，服务不奔溃就好了。
有这闲工夫打打游戏不好么。 |
 |
35
tramm 2022-09-27 10:50:08 +08:00
2 亿了, 加上索引, 没影响
|
 |
36
monetto 2022-09-27 11:38:15 +08:00
我们线上库大概 10 亿级，是直接物理机部署的。2T SSD ，CPU 是啥忘记了 ... 运行一切良好。读写分离 + 单表。
|
 |
37
xshell 2022-09-30 13:16:46 +08:00
|
 |
38
daoqiongsi1101 2022-10-17 13:08:39 +08:00
分库分表场景可以用腾讯云 TDSQL
|
Select Language