分表：垂直拆分、水平拆分
垂直拆分：根据业务将一个表拆分为多个表。
如：将经常和不常访问的字段拆分至不同的表中。由于与业务关系密切，目前的分库分表产品均使用水平拆分方式。
水平拆分：根据分片算法将一个表拆分为多个表。
如：按照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