关于分库分表的分歧

• 資深大佬 : ruanimal

  数据文件这么小，不分表也没啥吧

• 主 資深大佬 : linxiaoziruo

  @ruanimal 笔误，是一个 T ！

• 資深大佬 : optional

  看负载啊，负载不高干吗分

• 資深大佬 : xsm1890

  我去，一亿数据就一个 T，我司一亿五千万总文件才步到六十个 G 。是不是存太多大字段了，冗余字段了。感觉这才是需要优化的地方

• 資深大佬 : xx6412223

  瓶颈是业务来定义的。

• 資深大佬 : xsm1890

  如果索引数据五五开的情况下，平均行长度达到了 5000bit????一个数据页就 16kb，个人觉得很不合理啊

• 資深大佬 : opengps

  犯不着纠结这个，总量可控，读写结构合理，那么分不分表对于性能的影响可能真的很小，或者说实在想优化下，可以进行表分区（表分区的优势是对外表现仍然是单表结构）

• 主 資深大佬 : linxiaoziruo

  @xsm1890 兄弟，1 亿数据是单表数据，1T 数据是整个库
• 資深大佬 : mightofcode

  这点数据分个毛

• 資深大佬 : cheng6563

  1 亿数据，没范围查询，不嫌插入慢就没啥必要分吧。

• 資深大佬 : th00000

  同意 5 3 看法
  分库分表是根据业务来的, 要知道业务的瓶颈在哪里, 然后才能决定怎么分
  然而你 1 亿 的表 不是你们业务的瓶颈你分他干啥

• 資深大佬 : cco

  用到必须得分库了再去分，不要过度设计。

• 資深大佬 : zhihhh

  太小了的确不用分。

• 資深大佬 : sanggao

  你这高度理解不了 dba 的决定

• 資深大佬 : snappyone

  界限就是性能可能顶不住了就考虑拆分

• 資深大佬 : polyang

  同意 15 的观点，不是达到多少数量量就一定要分库分表，主要看性能，性能不行了，没办法从其他方面优化了，可以考虑分库分表

• 資深大佬 : wakzz

  上正解，主要看业务场景。有的表仅仅是做存储几乎不读，简单搞个冷备份就行了。如果当前业务场景下性能没问题，就暂时没必要为了分库分表而分库分表，毕竟分库分表就意味着风险和代码重构。