MySQL-单表上亿的数据量如何分表

发布于 2017-02-06 23:04:13 字数 68 浏览 1303 评论 2

数据库中有一个表有上亿的数据量,怎么优化?(主要是拆分,除了按业务拆分外,还有什么从技术角度的,可扩展性好的水平拆分方式)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夜无邪 2017-08-20 13:46:27

之前的几篇关于分表的,提到的分表策略不够详细,我在这篇中补充一些分表策略吧:

按号段分:

(1) user_id为区分,1~1000的对应table1,1001~2000的对应table2,以此类推,或者以id最后两位数字为区分,分到table00-table99表中;
优点:可部分迁移
缺点:数据分布不均

(2)hash取模分:
对user_id进行hash(或者如果user_id是数值型的话直接使用user_id 的值也可),然后用一个特定的数字,比如应用中需要将一个表切分成4个表的话,我们就用4这个数字对user_id的hash值进行取模运算,也就是user_id%4,这样的话每次运算就有四种可能:结果为1的时候对应table1;结果为2的时候对应table2;结果为3的时候对应table3;结果为0的时 候对应table4,这样一来就非常均匀的将数据分配到4个table中。当然还有其他一些算法,可以以user_name作为参数,进行 hash 运算,可参考 @php hash算法使用
优点:数据分布均匀
缺点:数据迁移的时候麻烦,不能按照机器性能分摊数据

(3)在认证库中保存数据库配置
就是建立一个table,这个table单独保存user_id到table的映射关系,每次访问数据库的时候都要先查询一次这个数据库,以得到具体的table信息,然后才能进行我们需要的查询操作。
优点:灵活性强,一对一关系
缺点:每次查询之前都要多一次查询,性能大打折扣

以上就是我们在开发中通常选择的方式,在一些复杂的项目中我们也可以混合使用这几种方式。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文