1. 分库分表与ShardingJdbc核心概念解析当单表数据量突破千万级时传统的单体数据库架构就会遇到明显的性能瓶颈。我经历过一个电商平台的订单表达到3000万条记录后即使加了索引查询响应时间也从毫秒级飙升到秒级。这时候就需要引入分库分表技术——把数据分散到多个数据库实例和物理表中。ShardingJdbc是Apache ShardingSphere的核心组件之一它通过轻量级的JDBC驱动层实现分库分表逻辑对业务代码几乎零侵入。相比传统的MyCat等中间件方案它不需要独立部署代理服务直接集成在应用层性能损耗更低。关键区别分库是水平扩展数据库实例如order_db1, order_db2分表是垂直拆分单表数据如order_0, order_1。两者常结合使用。2. 实战环境搭建与基础配置2.1 依赖引入与版本选择建议使用SpringBoot 2.7.x ShardingJdbc 5.3.2组合这是目前最稳定的版本搭配。Maven配置示例dependency groupIdorg.apache.shardingsphere/groupId artifactIdsharding-jdbc-spring-boot-starter/artifactId version5.3.2/version /dependency2.2 分片策略设计原则以电商订单表为例我们需要考虑分片键选择通常用user_id或order_id要保证高频查询能路由到具体分片分片算法哈希取模是最常用方式但对扩容不友好范围分片适合有时间序列特征的数据spring: shardingsphere: datasource: names: ds0,ds1 ds0: # 主库配置 type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/order_db0 username: root password: 123456 ds1: # 从库配置...3. 深度分片配置实战3.1 精确分片算法实现自定义精确分片策略示例按user_id的尾数分库public class UserIdPreciseShardingAlgorithm implements PreciseShardingAlgorithmLong { Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueLong shardingValue) { long userId shardingValue.getValue(); int suffix (int) (userId % 2); for (String each : availableTargetNames) { if (each.endsWith(String.valueOf(suffix))) { return each; } } throw new IllegalArgumentException(); } }3.2 分布式ID生成方案避免使用数据库自增ID推荐以下方案Snowflake算法默认包含在ShardingJdbc中UUID适合非连续查询场景美团Leaf等第三方服务配置示例spring: shardingsphere: rules: sharding: key-generators: snowflake: type: SNOWFLAKE props: worker-id: 1234. 高级特性与性能优化4.1 读写分离配置结合主从复制实现读写分离spring: shardingsphere: rules: replica-query: >// 自定义ID生成器 public class CustomSnowflakeGenerator implements KeyGenerator { private final SnowflakeShardingKeyGenerator delegate new SnowflakeShardingKeyGenerator(); Override public Comparable? generateKey() { // 添加业务前缀 return ORD_ delegate.generateKey(); } }6. 监控与运维实践6.1 集成Prometheus监控添加依赖dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-agent-metrics-prometheus/artifactId version5.3.2/version /dependency配置指标采集agent: metrics: prometheus: host: 0.0.0.0 port: 9090 props: jmx_exporter_config.yaml6.2 在线扩容方案扩容步骤停写受影响分片使用数据迁移工具如ShardingSphere-Scaling修改分片配置并灰度发布恢复写入关键点扩容后要更新分片算法建议采用一致性哈希算法减少数据迁移量我在实际项目中发现当分片数超过16个时连接池管理会成为瓶颈。建议每个物理库配置独立的连接池并合理设置maxPoolSize通常不超过CPU核心数*2。对于高频访问的分片可以适当增大连接数。
