mysql分表在真实项目中的实践

1. 数据分发策略

一般在水平拆分时，会遇到数据该如何分发的问题，单表时直接插入，那么分表/分库之后就多了一步选择的步骤，需要先选择对应的库/表之后，才能保存；

1.1 Range

按id范围分发数据：比如：1-200W存放到表1，200W-400W存放到表2等；
按日期范围分发数据：比如：202001数据存放到表1，202002数据存放到表2等，按月份进行划分；

根据range分发数据的特别：

1. 每张表中的数据量均匀且自带水平扩展；比如：以递增id分发每200W一张表，超数据量快速达到200W以上，自动将数据写入另一张表；
2. 使用不当容易产生数据不均匀的情况；比如：以日期分表时，如果某月内数据暴增，可能导致单表数据量过大的情况；

1.2 Hash

上面介绍了Range的方式，该方式简单易懂，但在真实使用场景使用却不太多：

1. 分库分表之后，id很少有递增的；
2. partition key需要在每次查询的时候都带上，如果是基于日期进行分区，那么查询时需要带上日期；
3. 数据过于分散，比如：商城系统用户想查询他的订单，那么它的订单可能分布在多张表中，不易查询；

那么，除了上面的Range的方式，还有一种分发方式，基于hash；
将订单的id通过一次hash函数的计算，得到一个数字，然后该数字mod分表的大小，得到存放数据的表名；

hash分发数据的特别：

1. hash在统计学里面，数据几乎是趋近均匀的；
2. hash方式不利于数据的水平扩展，所以需要在拆分表之前就尽可能的多拆分些表；

2. 分表在项目中的实践

2.1 日志表（接口日志、操作日志、审批日志）

一般TOB系统都会有这些功能来查询日常系统的操作日志或者是接口日志等，有这些日志的主要是目的是方便数据的追溯和问题的排查；
但此类日志表有以几特点：

1. 只查看近一月的日志；
2. 数据增长速度比较快；

对此类日志表未做分表之前，数据量过大之后，影响查询性能时，往往是通过DBA对表做一些归档操作；像我们现在的系统数据量相对较大，归档相对频繁；

我们的处理方式：对于此类没有业务意义的大数据量，我们采用定时任务去在当月月底归档上个月的数据，对此类表做分库分表的意义不大；建议是直接定时归档省去人力操作；

2.2 业务表数据分表未分库

2.2.1 用户表

我们的系统是TOB，用户量相对较小，不分表就可以满足业务，这里列举出来想对这种场景做个说明；
一般用户的查询主要是基于：用户名、手机号、邮箱，但在分表时该如何选取分片键呢？
如果我们选择手机号做分片键，那如果按邮箱查询时该怎么办呢？全表扫描？也行，效率很低；

中间表方式
我们可以选择用户id做分片键，如果遇到用户名、手机号、邮箱查询时该怎么办呢？我们可以再创建一张中间表（包含：用户id、用户名、手机号、邮箱）；用手机号查询时，先去中间表中查询出用户id，然后再通过用户id去用户分表里面去查询；

数据冗余方式
还有另外一种方案就是通过冗余：

可见，这种方式在用户表这个模块中并不适合；但这种方式也不是说没有用处，比如：招聘网站用户投递简历时，可分为用户查看和企业查看两种查看的方式不同，这时使用此方式可能比较合适；

2.2.2 某业务大表

上面提到的用户表的功能还是比较单一的采取中间表的方案就可以解决实际问题，但是对于业务表来说，它的查询非常之多，少说也至少得有8个以上，那对于这种情况，是不是还可以继续采用中间表的方案呢？
这种情况就不能再继续使用中间表的方案了：

1. 如果还继续采用上面的方式就不可行了，因为条件太多，中间表的字段也随之增多；
2. 对于用户表来说数据增长有限，但是对于业务单据来说，增长速度快，量大；

集成ES解决多查询条件问题
业务大表在分表时，使用单据ID进行分表，可以集成ES，将查询条件的字段（或者是全量数据）保存到ES中一份，这样查询时，先查询ES可以获单据的ID，然后通过单据ID再去数据库中查询单据，将结果集合并返回到页面；

这种方式会引入一个新的问题，就是ES中的数据与数据库保证一致问题，如果数据库是MYSQL我们可以通过订阅MYSQL的binlog日志，将binlog日志中的操作同步到ES中；

ES+HBase方式
在做分库分表时，调研过此方式，但项目中未实践（项目不配），这种方式可以针对海量数据，可以缓解ES和数据库的压力（上面方案有两种玩法，1.ES全量数据，复杂查询ES，2.ES保存查询字段，查到ID再去库里查记录）；
这种方式是将查询字段存放到ES中，然后通过ES查出一个rowkey(hbase的索引)，然后通过rowkey去Hbase中检索记录；

2.2.3 分表后的问题

分库分表之后，会给我们开发带来任何问题困扰，比如，单库拆分为多库之后，可能需要引入分布式事务；单表拆分多表，查询也不那么的方便了；

2.2.3.1 聚合、排序、分页查询问题

这个问题算是要在分库分表之前就已经要考虑清楚的，因为分库分表之后这些功能都已无法正常使用；
比如：我们对某张表水平切分64张表之后，如果没有中间件的帮助做 聚合统计的话，需要做全部分表的查询，比如循环64次数据库查询操作，然后把结果在代码里面做汇总；
当然这样会带来64次查询数据库的性能瓶颈，也可以使用多线程异常查询再汇总结果；

由此可见，分库分表之后虽然数据库瓶颈解决了，但会带来新的更多的问题；

2.2.3.2 join问题

对于join问题的处理方案也是首先看你join后想要取的数据，如果只是想通过id left join取对应的名称，那这种可以使用数据冗余的方式冗余到id表中；但如果名称如果可以变更，可能又牵扯到id表中的名称要不要变更的问题；

另外一种方式是，先在A表中取出数据，然后通过A表的与B表的关联条件，再去B表中分条查询，在程序端再做汇总；

上面列举的几种查询场景，都是在分库分表中常遇的几个问题，而我们在分库分表的时候是将数据冗余到了ES中，复杂的查询都是走的ES；

3. 数据如何迁移及扩容问题

3.1 数据迁移

在一般的开发中，分库分表都是对现有项目做的升级，都是真实在生产跑的项目，遇到了数据库瓶颈后采用的一种优化方式，那么优化后的分库分表上线之后，那历史数据又该怎么存放新的表中的问题；
常见的有两种方式：

3.1.1 停机迁移数据

这种方案简单粗暴，停机后，写迁移数据程序，读取旧表中的数据，然后通过分片规则重新写入到新表中；

优化：数据准确库高；缺点：迁移期间服务不可用；

3.1.2 不停机双写

这种方式已经相对普遍，在不停机的情况下解决数据迁移；
新增记录：

新增记录时，直接向分表中插入，不需要再向旧表中插入数据；
查询：

查询时，先向分表中查询，再向旧表中查询，然后将两个结果在程序中做聚合；

更新和删除：
更新和删除的和查询的逻辑一样，先去操作分表，然后操作旧表；

迁移数据后门：
如果数据量不是特别的大，比如千万这种，我们可以再写一个后门程序，在半夜无人使用的时候，取旧表中的数据，然后向分表中插入，然后再把旧表中的数据删除掉；

3.2 扩容问题

分库分表之后，在后期的发展过程中，又遇到类似问题，需要对分库或分表的数据再次拆分；一般情况下是在分库分表的时候，根据业务的未来发展情况一次分个够，以免后期再遇到扩容问题；
具体的迁移方案可以参考：这里