为什么要分表
Mysql是当前互联网系统中使用非常广泛的关系数据库,具有ACID的特性。
但是mysql的单表性能会受到表中数据量的限制,主要原因是B+树索引过大导致查询时索引无法全部加载到内存。读取磁盘的次数变多,而磁盘的每次读取对性能都有很大的影响。
这时一个简单可行的方案就是分表(当然土豪也可以堆硬件),将一张数据量庞大的表的数据,拆分到多个表中,这同时也减少了B+树索引的大小,减少磁盘读取次数,提高性能。
两种基础分表逻辑
说完了为什么要分表,下面聊聊业务开发中常见的两种基础的分表逻辑。
按日期分表
这种方式通常会在表名的最后加上年月日,主要适用于按日期划分的统计数据或操作记录。在线实时展示的只有最近表中的数据,其他数据用于离线统计等。
按id取模分表
这种方式需要一个id生成器,例如snowflake id或分布式id服务。它保证了相同id的数据都在一张表中,主要适用于保存用户基础信息,系统中的资源信息,购买记录等。当然这种分表方式扩展性较差,后期数据持续增多后需要按id大小分库再分表处理。
下面看下这两种分表逻辑在mybatis-plus中的实现。
Mybatis-plus中的分表实现
说到java的分表中间件,可能有人会想到sharding-jdbc,作为使用很广泛的一个分表中间件,功能也比较完善,但是使用它需要引入额外的jar包和增加学习成本。
实际上mybatis-plus本身就提供了一个分表的解决方案,配置使用都很简单,适合快速开发系统。
动态表名处理器
没错,mybatis-plus提供了动态表名处理器接口TableNameHandler
,只需要在系统中实现该接口,并作为插件加载到mybatis-plus中就可以使用,下面来看下详细的步骤。
3.4版本之前的动态表名接口是ITableNameHandler,需要和分页插件配合使用。
3.4版本新增了
TableNameHandler
,在方法参数上取消了MetaObject
。这里用最新的版本为例,使用方式差别不大。
假设我们的系统中有两种分表方式,按日期分表和按id取模分表。通过四个步骤来看下具体的使用示例。
1.创建日期表名处理器
先来看下日期处理的表名处理器,实现TableNameHandler
接口后,在dynamicTableName
方法中实现动态生成表名的逻辑,方法的返回值就是查询时要使用的表名。
/**
* 按天分表解析
*/
public class DaysTableNameParser implements TableNameHandler {
@Override
public String dynamicTableName(String sql, String tableName) {
String dateDay = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
return tableName + "_" + dateDay;
}
}
2.创建id取模表名处理器
再来看下按id取模表名处理器的实现,这个处理器相对日期处理就要复杂一些,主要原因为需要动态传入用于分表的id值。
在之前的版本中可以在方法中通过解析MetaObject
中带有的sql查询信息,获取分表使用的值。但是这种方式比较复杂,对于不同的QueryMapper
分析的方式不同,比较容易出错。新版本中的方法取消了MetaObject
参数,需要使用其他方式传入。
需要注意的是,表名处理器是作为mybatis-plus的插件,在项目启动时实例化的。这意味着,在运行过程中只有一个对象,多线程处理过程中,一个线程对参数的修改,会影响到其他线程。为了解决这个问题,可以使用ThreadLocal
来定义参数。
由于现在的框架中大部分会使用线程池,例如springboot web项目中的tomcat。所以在每次使用后,需要手动清除本次数据,防止线程复用时的影响。
具体实现如下:
/**
* 按id取模分表处理器
*/
public class IdModTableNameParser implements TableNameHandler {
private Integer mod;
//使用ThreadLocal防止多线程相互影响
private static ThreadLocal<Integer> id = new ThreadLocal