ShardingSphere分库分表基础配置与使用说明

一、ShardingSphere核心定位

ShardingSphere 是针对分布式数据库场景的中间件工具，核心作用是解决传统单库单表架构在数据量大、并发高时面临的性能瓶颈和扩展性问题，无需改造业务代码即可实现数据分布式管理。

二、核心功能：解决数据库分布式难题

ShardingSphere 核心能力聚焦分布式数据库核心痛点，主要包括：

分库分表（数据分片）

当单表数据量达到千万/亿级时，查询和写入性能急剧下降。通过中间件可将数据按规则拆分：
- 水平分片：按字段规则（如用户ID哈希、时间范围）分散到多个表/库；
- 垂直分片：按业务模块（如订单表、用户表）拆分到不同库。
  中间件自动处理分片路由，应用层像操作单库一样操作分布式数据库。
读写分离

针对"读多写少"场景，写入操作（INSERT/UPDATE/DELETE）路由到主库，读取操作（SELECT）路由到从库（依赖MySQL主从复制），提升整体吞吐量。
高可用与故障转移

监控数据库集群状态，主库故障时自动切换到备用主库，从库故障时将读请求路由到健康从库，减少服务中断风险。
分布式事务支持

解决跨分库操作的一致性问题（如订单表、支付表分布在不同库），提供SAGA、TCC等分布式事务方案，避免数据不一致。
全局序列与分布式ID

分库分表后传统自增ID会重复，中间件提供雪花算法、数据库自增等全局唯一ID生成策略，保证数据标识唯一性。

三、适用场景

适用于高并发、大数据量的业务系统，典型场景包括：

电商平台（订单、商品数据）
社交应用（用户动态、消息数据）
金融系统（交易记录、账户数据）
日志/监控系统（海量时序数据）

四、ShardingSphere整合步骤

4.1 引入依赖

在pom.xml中添加ShardingSphere-JDBC的Spring Boot Starter依赖：

xml 复制代码

<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc-core-spring-boot-starter</artifactId>
    <version>5.2.1</version>
</dependency>

4.2 修改配置文件（application.yml）

以「订单表（orders）、订单明细表（order_detail）、订单支付记录表（orders_pay_record）」为例，配置如下：

yaml 复制代码

# ==================== ShardingSphere 配置 ====================
shardingsphere-config:
  # 1. 数据库连接配置
  driver-class-name: com.mysql.cj.jdbc.Driver
  jdbc-url: jdbc:mysql://127.0.0.1:3306/xxxxx?characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&allowMultiQueries=true&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=Asia/Shanghai&nullCatalogMeansCurrent=true&allowPublicKeyRetrieval=true
  username: xxxx  # 替换为实际数据库用户名
  password: xxxxx  # 替换为实际数据库密码
  
  # 2. 连接池配置
  maximum-pool-size: 300  # 最大连接数
  minimum-idle: 10        # 最小空闲连接数
  
  # 3. 分表配置（按逻辑表划分）
  tables:
    - logic-table: orders  # 订单表（逻辑表名）
      actual-data-nodes: ds0.orders,ds0.orders_25_{01..12}  # 实际数据节点（库.表）
      sharding-column: sale_date  # 分表键（按销售日期分片）
      algorithm-name: orders-by-month  # 关联的分片算法
    
    - logic-table: order_detail  # 订单明细表（逻辑表名）
      actual-data-nodes: ds0.order_detail,ds0.order_detail_25_{01..12}  # 实际数据节点
      sharding-column: order_id  # 分表键（按订单ID关联分片）
      algorithm-name: orderdetail-by-orderid  # 关联的分片算法
    
    - logic-table: orders_pay_record  # 订单支付记录表（逻辑表名）
      actual-data-nodes: ds0.orders_pay_record,ds0.orders_pay_record_25_{01..12}  # 实际数据节点
      sharding-column: orders_id  # 分表键（按订单ID关联分片）
      algorithm-name: orderpay-by-orderid  # 关联的分片算法
  
  # 4. 分片算法配置（自定义算法类路径）
  algorithms:
    - name: orders-by-month
      class-name: com.xxx.sharding.OrdersByMonthShardingAlgorithm  # 订单表按月分片算法类
    
    - name: orderdetail-by-orderid
      class-name: com.xxx.sharding.OrderDetailByOrderIdShardingAlgorithm  # 订单明细表按订单ID分片算法类
    
    - name: orderpay-by-orderid
      class-name: com.xxx.sharding.OrdersPayRecordByOrderIdShardingAlgorithm  # 支付记录表按订单ID分片算法类
  
  # 5. 绑定表配置（优化多表关联查询）
  binding-tables: orders,order_detail,orders_pay_record  # 关联紧密的表设为绑定表，避免笛卡尔积扫描
  
  # 6. SQL日志配置（开发环境调试用）
  sql-show: true  # 打印路由后的实际SQL

4.3 配置核心解析

数据源接管 ：ShardingSphere 会自动创建分布式数据源，禁止手动配置@Bean DataSource，否则会冲突并触发 Spring Boot 默认 H2 数据库。
绑定表优化：将关联紧密的三张表设为绑定表，ShardingSphere 会按分表键精准路由到对应分表，避免多表关联时的全表扫描。

五、使用说明与关键注意事项

5.1 日常使用方式

整合完成后，无需修改业务代码，正常操作orders、order_detail、orders_pay_record等逻辑表即可。ShardingSphere 会自动拦截SQL请求，根据配置的分片算法路由到对应的实际分表。

5.2 核心注意事项

数据源冲突规避（⚠️ 关键）
- 禁止手动配置DataSource Bean：ShardingSphere 会自动创建并管理分布式数据源，手动定义会导致配置冲突，Spring Boot 会默认回退到 H2 数据库，造成业务异常。
- 若使用 Seata 分布式事务，需禁用 Seata 数据源代理（ShardingSphere 已接管数据源，双重代理会冲突）。
分表键选择原则
- 优先选择查询频率高的字段（如订单表sale_date），避免无分表键查询时的全表扫描；
- 关联表必须用"对齐逻辑"的分表键（如order_id），确保数据落在同一张分表，否则会触发跨表关联（性能差）。
分表预处理

ShardingSphere 不自动创建分表，需提前在 MySQL 中手动创建实际分表（如orders_202501、order_detail_202501），表结构需与逻辑表一致。
SQL语法限制
- 避免使用SELECT *，建议明确字段名（防止分表字段缺失导致数据异常）；
- 不支持ORDER BY非分表键 + LIMIT跨分表（可能导致结果顺序错误），具体参考 ShardingSphere 官方SQL支持文档。
事务支持
- 单库分表场景：使用 Spring 普通@Transactional即可保证事务一致性；
- 跨库分表场景：需开启 ShardingSphere 分布式事务（如 SAGA、TCC 模式）。

六、总结与扩展方向

6.1 核心优势

零业务改造：无需修改现有业务代码，降低分库分表迁移成本；
配置简洁：通过 YAML 配置即可完成分片规则定义，无需复杂编码；
关联高效：绑定表配置确保多表关联时的精准路由，避免性能损耗。

6.2 扩展方向

分库扩展 ：在datasource.names中添加ds1，修改actual-data-nodes为ds${0..1}.orders_xxx，实现分库分表；
读写分离 ：添加主从数据源，配置readwrite-splitting规则，将读请求路由到从库，缓解主库压力；
冷热分离 ：将1年以上的冷数据路由到独立分表（如orders_cold_2024），提升热数据查询速度。