首先，我们先说为什么不按照卖家分表？

因为我们知道，电商网站上面是有很多买家和卖家的，但是，一个大的卖家可能会产生很多订单，比如像苏宁易购、当当等这种店铺，他每天在天猫产生的订单量就非常的大。如果按照卖家Id分表的话，那同一个卖家的很多订单都会分到同一张表。

那就会使得有一些表的数据量非常的大，但是有些表的数据量又很小，这就是发生了数据倾斜。这个卖家的数据就变成了热点数据，随着时间的增长，就会使得这个卖家的所有操作都变得异常缓慢。

但是，买家ID做分表字段就不会出现这类问题，因为一个不太容易出现一个买家能把数据买倾斜了。

但是需要注意的是，我们说按照买家Id做分表，保证的是同一个买家的所有订单都在同一张表 ，并不是要给每个买家都单独分配一张表。

我们在做分表路由的时候，是可以设定一定的规则的，比如我们想要分1024张表，那么我们可以用买家ID或者买家ID的hashcode对1024取模，结果是0000-1023，那么就存储到对应的编号的分表中就行了。

如果按照买家Id进行了分表，那卖家的查询怎么办，这不就意味着要跨表查询了吗？

首先，业务问题我们要建立在业务背景下讨论。电商网站订单查询有几种场景？

首先，我们用买家ID做了分表，那么买家来查询的时候，是一定可以把买家ID带过来的，我们直接去对应的表里面查询就行了。

那如果是卖家查呢？卖家查询的话，同样可以带卖家id过来，那么，我们可以有一个基于binlog、flink等准实时的同步一张卖家维度的分表，这张表只用来查询，来解决卖家查询的问题。

本质上就是用空间换时间的做法。

不知道大家看到这里会不会有这样的疑问：同步一张卖家表，这不又带来了大卖家的热点问题了吗？

首先，我们说同步一张卖家维度的表来，但是其实所有的写操作还是要写到买家表的，只不过需要准实时同步的方案同步到卖家表中。也就是说，我们的这个卖家表理论上是没有业务的写操作，只有读操作的。

所以，这个卖家库只需要有高性能的读就行了，那这样的话就可以有很多选择了，比如可以部署到一些配置不用那么高的机器、或者其实可以干脆就不用MYSQL，而是采用HBASE、PolarDB、Lindorm等数据库就可以了。这些数据库都是可以海量数据，并提供高性能查询的。

还有呢就是，大卖家一般都是可以识别的，提前针对大卖家，把他的订单，再按照一定的规则拆分到多张表中。因为只有读，没有写操作，所以拆分多张表也不用考虑事务的问题。

选定了分表字段之后，如何基于这个分表字段来准确的把数据分表到某一张表中呢？

这就是分表算法要做的事情了，但是不管什么算法，我们都需要确保一个前提，那就是同一个分表字段，经过这个算法处理后，得到的结果一定是一致的，不可变的。

通常情况下，当我们对order表进行分表的时候，比如我们要分成128张表的话，那么得到的128表应该是:order_0000、order_0001、order_0002.....order_0126、order_0127。

通常的分表算法有以下几种：

在分库分表时，我们是事先可以知道要分成多少个库和多少张表的，所以，比较简单的就是取模的方式。

比如我们要分成128张表的话，就用一个整数来对128取模就行了，得到的结果如果是0002，那么就把数据放到order_0002这张表中。

那如果分表字段不是数字类型，而是字符串类型怎么办呢？有一个办法就是哈希取模，就是先对这个分表字段取Hash，然后在再取模。

但是需要注意的是，Java中的hash方法得到的结果有可能是负数，需要考虑这种负数的情况。

前面两种取模方式都比较不错，可以使我们的数据比较均匀的分布到多张分表中。但是还是存在一个缺点。

那就是如果需要扩容二次分表，表的总数量发生变化时，就需要重新计算hash值，就需要涉及到数据迁移了。

为了解决扩容的问题，我们可以采用一致性哈希的方式来做分表。

一致性哈希可以按照常用的hash算法来将对应的key哈希到一个具有2^32次方个节点的空间中，形成成一个顺时针首尾相接的闭合的环形。所以当添加一台新的数据库服务器时，只有增加服务器的位置和逆时针方向第一台服务器之间的键会受影响。

涉及到分库分表，就会引申出分布式系统中唯一主键ID的生成问题，因为在单表中我们可以用数据库主键来做唯一ID，但是如果做了分库分表，多张单表中的自增主键就一定会发生冲突。那就不具备全局唯一性了。

那么，如何生成一个全局唯一的ID呢？有以下几种方式。

很多人对UUID都不陌生，它是可以做到全局唯一的，而且生成方式也简单，但是我们通常不推荐使用他做唯一ID，首先UUID太长了，其次字符串的查询效率也比较慢，而且没有业务含义，根本看不懂。

多张单表生成的自增主键会冲突，但是如果所有的表中的主键都从同一张表生成是不是就可以了。

所有的表在需要主键的时候，都到这张表中获取一个自增的ID。

这样做是可以做到唯一，也能实现自增，但是问题是这个单表就变成整个系统的瓶颈，而且也存在单点问题，一旦他挂了，那整个数据库就都无法写入了。

为了解决单个数据库做自曾主键的瓶颈及单点故障问题，我们可以引入多个表来一起生成就行了。

但是如何保证多张表里面生成的Id不重复呢？如果我们能实现以下的生成方式就行了：

实例1生成的ID从1000开始，到1999结束。

实例2生成的ID从2000开始，到2999结束。

实例3生成的ID从3000开始，到3999结束。

实例4生成的ID从4000开始，到4999结束。

这样就能避免ID重复了，那如果第一个实例的ID已经用到1999了怎么办？那就生成一个新的起始值：

实例1生成的ID从5000开始，到5999结束。

实例2生成的ID从6000开始，到6999结束。

实例3生成的ID从7000开始，到7999结束。

实例4生成的ID从8000开始，到8999结束。

我们把步长设置为1000，确保每一个单表中的主键起始值都不一样，并且比当前的最大值相差1000就行了。

雪花算法也是比较常用的一种分布式ID的生成方式，它具有全局唯一、递增、高可用的特点。

雪花算法生成的主键主要由 4 部分组成，1bit符号位、41bit时间戳位、10bit工作进程位以及 12bit 序列号位。

时间戳占用41bit，精确到毫秒，总共可以容纳约69年的时间。

工作进程位占用10bit，其中高位5bit是数据中心ID，低位5bit是工作节点ID，做多可以容纳1024个节点。

序列号占用12bit，每个节点每毫秒0开始不断累加，最多可以累加到4095，一共可以产生4096个ID。

所以，一个雪花算法可以在同一毫秒内最多可以生成1024 X 4096 = 4194304个唯一的ID。

现在叫ShardingSphere（Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成）。它定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。

开源地址：https://shardingsphere.apache.org

TDDL 是淘宝开源的一个用于访问数据库的中间件， 它集成了分库分表， 读写分离，权重调配，动态数据源配置等功能。封装 jdbc 的 DataSource给用户提供统一的基于客户端的使用。

开源地址：https://github.com/alibaba/tb_tddl

Mycat是一款分布式关系型数据库中间件。它支持分布式SQL查询，兼容MySQL通信协议，以Java生态支持多种后端数据库，通过数据分片提高数据查询处理能力。

开源地址：https://github.com/MyCATApache/Mycat2

分库分表之后，会带来很多问题。

首先，做了分库分表之后，所有的读和写操作，都需要带着分表字段，这样才能知道具体去哪个库、哪张表中去查询数据。如果不带的话，就得支持全表扫描。

但是，单表的时候全表扫描比较容易，但是做了分库分表之后，就没办法做扫表的操作了，如果要扫表的话就要把所有的物理表都要扫一遍。

还有，一旦我们要从多个数据库中查询或者写入数据，就有很多事情都不能做了，比如跨库事务就是不支持的。

所以，分库分表之后就会带来因为不支持事务而导致的数据一致性的问题。

其次，做了分库分表之后，以前单表中很方便的分页查询、排序等等操作就都失效了。因为我们不能跨多表进行分页、排序。

总之，分库分表虽然能解决一些大数据量、高并发的问题，但是同时也会带来一些新的问题。所以，在做数据库优化的时候，还是建议大家优先选择其他的优化方式，最后再考虑分库分表。