[MySQL] 分库分表需要考虑的问题

概述随着业务的增长，一般的公司都会经历一个从单库单表到分库分表的过程 , 需要考虑以下要素判断是否开始分库分表 1. 如果mysql单库的QPS超过1000就要考虑分库了 , 一般根据业务进行分库 目前新

随着业务的增长，一般的公司都会经历一个从单库单表到分库分表的过程,需要考虑以下要素判断是否开始分库分表

1. 如果MysqL单库的QPS超过1000就要考虑分库了,一般根据业务进行分库

目前新浪邮箱的主库是sinanet  各种辅助库 userservice客服系统  sinastore 文件存储库 entsales 销售系统库

 

2. 单表的数据量非常大时,需要考虑分表,超过1000万就要考虑了,因为此时b+树索引的高度是3-5左右

 如果有单字段特别大,就要把该字段独立出来,这就是垂直分表,遵循冷热拆分,大小拆分

这里基本在设计的时候就已经考虑好了,一般不会出现这种情况

 

如果是数据量特别大,就要结合业务需求和产品特性,选择合适的拆分算法

如何切分？
a：哈希取模算法 hash(ID)/NUM，
本表的ID是数据库auto_incr ID，hash拆分后数据分散是特别均匀的，但是后面的NUM设置没有经验值，只能依靠人工来计算; max_row/day_incr= year ，保证能扛住近四年的数据增量。
考虑到后续扩展表的数据时，数据迁移会比较难做。

新浪邮箱的用户表是根据默认域邮箱hash取模进行的拆分

b：一致性hash算法
为了保证后续迁移数据影响面较小，建议使用一致性hash算法。

新浪邮箱的订单表是根据一致性hash算法根据,不同值的范围大小选择存储表节点

c：range(timestamp)
具有天然的时间字段，非常好拆分，具有很好的扩展性。
目前查询都是带时间戳的，所以会出现表的访问冷热不均。但同时也避免了跨节点join等问题

新浪邮箱用户的日志表是根据月份加哈希拆分了 1024张表

 

 如何迁移数据？

这是不可避免的问题，可以采用了实时数据双写，历史数据采用脚本导入的方式，在线上数据对齐后，慢慢将流量灌到新的db上。

总结

以上是内存溢出为你收集整理的[MySQL] 分库分表需要考虑的问题 全部内容，希望文章能够帮你解决[MySQL] 分库分表需要考虑的问题 所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。