这是一个创建于 1938 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司新来 DBA，一直在强调目前数据量没必要分库分表。我们目前最大的单表数据量是 1 亿，整个库的数据文件大小 1 个 G 。 我不太能理解分库分表的界限在哪里，到了这个界限会引发哪些性能瓶颈?
第 1 条附言 · 2020 年 9 月 29 日
不好意思，数据文件是一个 T，笔误啊
 |
1
ruanimal 2020 年 9 月 29 日
数据文件这么小，不分表也没啥吧
|
 |
2
linxiaoziruo OP @ruanimal 笔误，是一个 T ！
|
 |
3
optional 2020 年 9 月 29 日 via iPhone
看负载啊，负载不高干吗分
|
 |
4
xsm1890 2020 年 9 月 29 日
我去，一亿数据就一个 T，我司一亿五千万总文件才步到六十个 G 。是不是存太多大字段了，冗余字段了。感觉这才是需要优化的地方
|
 |
5
xx6412223 2020 年 9 月 29 日
瓶颈是业务来定义的。
|
|
6
xsm1890 2020 年 9 月 29 日
如果索引数据五五开的情况下，平均行长度达到了 5000bit????一个数据页就 16kb，个人觉得很不合理啊
|
 |
7
opengps 2020 年 9 月 29 日
犯不着纠结这个，总量可控，读写结构合理，那么分不分表对于性能的影响可能真的很小，或者说实在想优化下，可以进行表分区（表分区的优势是对外表现仍然是单表结构）
|
|
8
linxiaoziruo OP @xsm1890 兄弟，1 亿数据是单表数据，1T 数据是整个库
|
 |
9
mightofcode 2020 年 9 月 29 日
这点数据分个毛
|
 |
10
cheng6563 2020 年 9 月 29 日
1 亿数据，没范围查询，不嫌插入慢就没啥必要分吧。
|
 |
11
th00000 2020 年 9 月 29 日
同意 5 楼 3 楼 看法
分库分表是根据业务来的, 要知道业务的瓶颈在哪里, 然后才能决定怎么分 然而你 1 亿 的表 不是你们业务的瓶颈你分他干啥 |
 |
12
cco 2020 年 9 月 29 日
用到必须得分库了再去分，不要过度设计。
|
 |
13
zhihhh 2020 年 9 月 29 日
太小了的确不用分。
|
 |
14
sanggao 2020 年 9 月 29 日  2
你这高度理解不了 dba 的决定
|
 |
15
snappyone 2020 年 9 月 29 日
界限就是性能可能顶不住了就考虑拆分
|
 |
16
polyang 2020 年 9 月 30 日
同意 15 楼的观点，不是达到多少数量量就一定要分库分表，主要看性能，性能不行了，没办法从其他方面优化了，可以考虑分库分表
|
 |
17
wakzz 2020 年 9 月 30 日
楼上正解，主要看业务场景。有的表仅仅是做存储几乎不读，简单搞个冷备份就行了。如果当前业务场景下性能没问题，就暂时没必要为了分库分表而分库分表，毕竟分库分表就意味着风险和代码重构。
|
Select Language