摘要：在当今互联网应用飞速发展的时代，数据量呈现爆炸式增长。对于许多互联网软件开发人员而言，如何高效处理海量数据成为了一个亟待解决的关键问题。当数据库中的单表数据突破千万级后，查询速度往往会变得极为缓慢，甚至可能出现锁表风险，严重影响系统的性能和用户体验。此时，分库
在当今互联网应用飞速发展的时代，数据量呈现爆炸式增长。对于许多互联网软件开发人员而言，如何高效处理海量数据成为了一个亟待解决的关键问题。当数据库中的单表数据突破千万级后，查询速度往往会变得极为缓慢，甚至可能出现锁表风险，严重影响系统的性能和用户体验。此时，分库分表技术便成为了应对这一挑战的有力武器。本文将聚焦于 Spring Boot3 中如何实现分库分表操作，帮助广大开发者掌握这一重要技能。
（一）分库
分库，即将数据分散到多个数据库实例中。例如，我们可以创建order_db0、order_db1等多个数据库实例，将不同的数据存储在不同的库中。这样做的主要目的是降低单库的压力，当一个库面临高并发读写请求时，多个库可以分担负载，从而提升整体性能。
（二）分表
分表，则是把单表数据拆分到多个子表。以order表为例，可以拆分成order_0、order_1等子表。通过这种方式，避免单表数据量过大，提升查询效率。因为在查询时，数据库只需要在较小的子表中进行检索，减少了扫描的数据量。
（三）常见策略
按取模：比如通过user_id % 2来决定数据存储在哪个库或表。如果user_id % 2的结果为 0，则将相关数据存储在一个库或表中；结果为 1，则存储在另一个库或表中。这种方式能较为均匀地分散数据。
按时间范围：例如按月分表，将每个月的数据存储在不同的表中。对于一些时间序列性较强的数据，如订单表，按时间范围分表便于数据的管理和查询，同时也符合业务逻辑。
按业务逻辑：以地区分库为例，如果业务涉及不同地区，且不同地区的数据量较大，可以按照地区将数据存储在不同的数据库中，方便进行区域性的数据分析和管理。
（一）环境准备
添加依赖：在pom.xml文件中添加 ShardingSphere 相关依赖，如下所示：
org.apache.shardingsphereshardingsphere-jdbc-core-spring-boot-starter5.3.2这个依赖是使用 ShardingSphere 实现分库分表的基础，它提供了与 Spring Boot 集成的相关功能。
（二）配置分库分表规则
在application.yml文件中进行分库分表规则的配置：
spring:shardingsphere:datasource:names: db0,db1db0:type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3306/db0username: rootpassword: rootdb1:# 配置同db0，指向不同数据库实例type: com.zaxxer.hikari.HikariDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverjdbc-url: jdbc:mysql://localhost:3306/db1username: rootpassword: rootrules:sharding:tables:t_order:actual-data-nodes: db$->{0..1}.t_order_$->{0..1} # 分库分表表达式database-strategy:standard:sharding-column: user_idsharding-algorithm-name: db-modtable-strategy:standard:sharding-column: order_idsharding-algorithm-name: table-modsharding-algorithms:db-mod:type: MODprops:sharding-count: 2table-mod:type: MODprops:sharding-count: 2在这段配置中，我们定义了两个数据源db0和db1。对于table_order表，通过actual-data-nodes指定了数据节点，即数据将被存储在db0.t_order_0、db0.t_order_1、db1.t_order_0、db1.t_order_1这四个表中。分库策略基于user_id字段，使用取模算法db-mod；分表策略基于order_id字段，同样使用取模算法table-mod，并且取模的基数都是 2。
（三）编写分片逻辑（Java 代码）
订单实体类：创建一个Order类，用于表示订单实体，并使用相关注解进行配置：
import com.baomidou.mybatisplus.annotation.TableName;import lombok.Data;import java.math.BigDecimal;@Data@TableName("t_order")public class Order {private Long orderId;private Long userId;private BigDecimal amount;// 其他字段...}这里使用了@Data注解简化了代码，自动生成了getter、setter等方法；@TableName注解指定了该实体对应的数据库表名为t_order。
Mapper 接口：使用 MyBatis-Plus 创建OrderMapper接口，继承BaseMapper，如下：
import com.baomidou.mybatisplus.core.mapper.BaseMapper;import org.apache.ibatis.annotations.Mapper;@Mapperpublic interface OrderMapper extends BaseMapper {}这个接口将用于对Order表进行数据库操作，MyBatis-Plus 会自动为其生成基本的 CRUD 方法。
（四）插入测试数据
编写测试代码插入数据，如下：
import org.springframework.beans.factory.annotation.Autowired;import org.springframework.web.bind.annotation.GetMapping;import org.springframework.web.bind.annotation.RestController;@RestControllerpublic class TestController {@Autowiredprivate OrderMapper orderMapper;@GetMapping("/testInsert")public String testInsert {Order order = new Order;order.setUserId(123L);order.setOrderId(System.currentTimeMillis);order.setAmount(new BigDecimal("100.00"));orderMapper.insert(order);return "数据插入成功";}}在这段代码中，当访问/testInsert接口时，会创建一个Order对象并设置相关属性，然后通过OrderMapper将数据插入数据库。ShardingSphere 会根据之前配置的分库分表规则，自动将数据路由到合适的库表中。
效果验证（一）数据分布
根据我们之前设置的分库分表规则，当user_id % 2 = 0时，数据会写入db0.t_order_0或db0.t_order_1；当user_id % 2 = 1时，数据会写入db1.t_order_0或db1.t_order_1。通过查看数据库中的数据，可以验证数据是否按照预期的规则进行了分布。
（二）查询性能
在分库分表之前，假设单表数据量非常大，查询可能会变得很慢。而分库分表之后，由于单表数据量减少了 50%，数据库的索引效率大幅提升。例如，原本查询一条数据可能需要数秒甚至更长时间，分库分表后，查询时间可能缩短到几百毫秒甚至更短，大大提升了系统的响应速度。
避坑指南（一）分布式事务
在分库分表的场景下，分布式事务是一个需要重点关注的问题。因为数据分布在不同的库中，传统的本地事务无法满足需求。此时，可以使用 Seata 或柔性事务补偿机制来解决。Seata 是一款开源的分布式事务解决方案，通过与 ShardingSphere 结合，可以实现分布式事务的管理。柔性事务补偿机制则是通过业务层面的补偿操作，来保证数据的最终一致性。例如，在一个涉及多个库的订单创建场景中，如果某个库的操作失败，通过柔性事务补偿机制，可以回滚已经成功的操作，或者进行相应的补偿操作，确保整个业务流程的正确性。
（二）全局 ID 生成
在分库分表环境下，为了保证数据的唯一性，需要一个全局唯一的 ID 生成策略。推荐使用 Snowflake 算法，ShardingSphere 内置支持该算法。Snowflake 算法生成的 ID 由时间戳、机器 ID、序列号等部分组成，能够在分布式环境下生成唯一且有序的 ID。例如，在插入数据时，使用 Snowflake 算法生成的 ID 可以确保不同库表中的数据 ID 不会冲突，方便数据的管理和关联查询。
（三）跨库查询
尽量避免在分库分表后进行跨库 JOIN 查询。因为跨库 JOIN 会涉及多个数据库实例的交互，性能开销较大。如果确实需要进行跨库数据的整合，可以通过业务层聚合数据的方式来实现。例如，先分别从不同的库中查询出需要的数据，然后在业务层进行数据的合并和处理，这样可以减少数据库层面的复杂操作，提升系统的整体性能。
通过本文的介绍，我们详细了解了在 Spring Boot3 中使用 ShardingSphere 实现分库分表的方法。从环境准备、配置分库分表规则、编写分片逻辑到效果验证以及避坑指南，每一个环节都至关重要。Spring Boot + ShardingSphere 的分库分表方案，具有几乎零侵入代码的优势，开发者通过简单的配置即可实现数据分片。无论是应对双十一大促等极端高并发场景，还是日常业务中的海量数据处理，这一方案都能让开发者游刃有余。希望广大互联网软件开发人员能够掌握这一技术，为打造高性能、高扩展性的互联网应用奠定坚实基础。
来源：从程序员到架构师一点号