MySQL的分库分表策略及应用场景

分库

解决单台数据库的性能问题

水平分库：取模

确定需要将数据平均分配到多少个库中，也就是：库容量

对用户ID进行取模，user_id%库容量，结果为0的在第一个库，结果为1的在第二个库。。。

垂直分库：根据业务拆分

订单数据过多时可给订单单独创建数据库

分表

解决单表海量数据的查询性能问题

水平分表

以行为单位对数据进行拆分

分表之后，所有表的结构都是一样的

解决表数据太多的问题

方法：确定需要将数据平均分配到多少张表中，也就是：表容量

           对用户ID进行取模，user_id%表容量，结果为0的在第一张表，结果为1的在第二张表。。。

垂直分表

按列分为多张表，多张表通过主键进行关联，从而组成完整的数据

分表之后，每张表的结构都不相同

解决列太多的问题

同时分库分表

中间变量　＝ user_id%（库容量*每个库的表容量）

库号　＝　取整（中间变量／每个库的表容量）

表号　＝　中间变量％每个库的表容量

 弊端

原本跨表的事物变成了分布式事物；

由于记录被切分到不同的数据库和不同的数据表中，难以进行多表关联查询，并且查询要指定数据的库号表号。

对系统进行进一步的扩阵容（库号表号变更），将变得非常不方便，需要我们重新进行数据迁移。

多少数据量分表合适

理论500w可分表（分表后比较快）

实际1000w-2000w左右才分表

总之不能超过5000w才分表，5000w是索引极限

补充：如果订单数据需要做出统计，统计每个月销售量之类的信息，可以使用按月分表，否则，不建议，因为可能会造成某个月份数据太多，而某个月份数据很少的情况