分表需要解决的问题 & 基于MyBatis 的轻量分表落地方案

Posted 快鸟

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分表需要解决的问题 & 基于MyBatis 的轻量分表落地方案相关的知识,希望对你有一定的参考价值。

分表:垂直拆分、水平拆分
垂直拆分:根据业务将一个表拆分为多个表。
如:将经常和不常访问的字段拆分至不同的表中。由于与业务关系密切,目前的分库分表产品均使用水平拆分方式。
水平拆分:根据分片算法将一个表拆分为多个表。
如:按照ID的最后一位以3取余,尾数是1的放入第1个库(表),尾数是2的放入第2个库(表)等。

解决的问题:单纯的分表可以解决数据量过大导致检索变慢的问题。

分表无法解决过多并发请求访问同一个库,导致数据库响应变慢的问题。所以通常水平拆分都至少要采用分库的方式,用于一并解决大数据量和高并发的问题。这也是部分开源的分片数据库中间件只支持分库的原因。

分表不可替代的场景:最常见的分表需求是事务问题。
同在一个库则不需考虑分布式事务,善于使用同库不同表可有效避免分布式事务带来的麻烦。目前强一致性的分布式事务由于性能问题,导致使用起来并不一定比不分库分表快。目前采用最终一致性的柔性事务居多。分表的另一个存在的理由是,过多的数据库实例不利于运维管理。

综上所述,最佳实践是合理地配合使用分库+分表。

https://blog.csdn.net/u4110122855/article/details/50670503


MyBatis轻量分表落地方案:


分表需要解决的问题:(基于MyBatis来说明)
1. SQL解析
2. SQL改写
3. SQL执行
4. 结果合并

1. SQL解析
SQL语法树解析,为SQL改写做准备

2. SQL改写
按分片规则将 SQL 进行改写。
做为一个中间件产品,需要屏蔽分表的细节,到底分了多少个表,对使用者来说应该是透明的。所以使用者写出的 SQL 中的表是一个虚拟的表。
例如:有表 user_0, user_1,分片规则是 id%2
使用者写出的insert 语句:insert into user(id, name) values(1, ‘张三‘)
那么中间件需要将 SQL 改写为:insert into user_1(id, name) values(1, ‘张三‘)

改写出的 SQL 可能不止一条,例如:select * from user where id in (1, 2)
改写后的 SQL 应该是:select * from user_0 where id in (1, 2)
select * from user_1 where id in (1, 2)

3. SQL执行
MyBatis执行 SQL 时,最后是通过 PreparedStatementHandler#instantiateStatement(Connection) 来获取 Statement 的。它会从 BoundSql里面取需要执行的 sql 语句。
通过跟代码发现, BoundSql 是从 MappedStatement 中取出来的。
所以,我们 SQL 执行时,可以通过 MyBatis 的拦截器拦截 MappedStatement (即:Executor的query、update方法),然后改写 MappedStatement#getBoundSql()就可以了。

4. 结果合并
由于 SQL 改写后,我们需要执行的 SQL 不只一条,所以,当 SQL 有多条时,我们就需要将 SQL 执行的结果集合并出最终的结果。


基于MyBatis 的轻量分表实现:https://gitee.com/kkk001/mybatis-shard

以上是关于分表需要解决的问题 & 基于MyBatis 的轻量分表落地方案的主要内容,如果未能解决你的问题,请参考以下文章

基于Mybatis手撸一个分表插件

基于Mybatis手撸一个分表插件

Sharding +SpringBoot+Mybatis 无迁移的分库分表方案

浅谈mysql数据库分库分表那些事

谈谈利用Mybatis分库分表

mybatis-plus小技能: 分表策略(按年分表和按月分表)