分片键的考量

什么是分片键

用于将数据库（表）水平拆分的数据库字段。 例：将订单表中的订单主键的尾数取模分片。

简单来说，我们将短链接表拆分了 16 张分表，那用户新增短链接，怎么知道短链接记录应该放到哪张表里？这就需要用到分片键了，通过分片键进行一定规则（短链接表 t_link 使用的 HASH_MOD 方式）的运算，最终得到一个下标，这也就是我们要插入的分表位置。

得到一个下标指的是从 0-15 获取个值，然后和 t_link_ 一拼接，就是我们 MySQL 数据库中的真实数据库表名称。

选择分片键的角度

有共性、少更改

真实业务场景

分表后，我们查询数据库 SQL 语句时，必须要带上分片键，否则会走全部分片表路由，性能较差。

为什么不用 full_short_url 分片，这样还可以少个路由表。不过，从我们真实业务场景种，这个是行不通的。

根据我们的功能原型得知，短链接是根据分组访问的，那么查询条件中就必须要带一个 Gid。如果我们按照full_short_url字段进行分表，相当于这个分页查询接口如果没有分片键分组标识 Gid 字段的话，就会扫描全部分片表，出现读扩散问题。

那 t_link_goto 表是做什么的呢？

用户通过浏览器访问短链接时，仅有短链接值，没有 Gid 的，所以我们就要建立个路由表，也就是 t_link_goto 进行缓存短链接和 Gid 的关系。

CREATE TABLE `t_link_goto` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'ID',
  `gid` varchar(32) DEFAULT 'default' COMMENT '分组标识',
  `full_short_url` varchar(128) DEFAULT NULL COMMENT '完整短链接',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1768890503757107203 DEFAULT CHARSET=utf8mb4;

通过短链接 full_short_url 查询 t_link_goto 表，获取到对应的 Gid，进而再去查询 t_link 表，这样就不会出现读扩散问题。

分片框架选择

如果项目对功能需求较高，希望在一个较为活跃的社区中获取支持，且对数据库的支持要求较高，那么 ShardingSphere 可能是一个更好的选择。如果项目相对简单，对生态和社区支持要求不高，那么 Mycat 也是一个稳定的选择。

咱们在项目中使用了 ShardingSphere-JDBC 的形式进行分表处理。