分库分表全解析：从原理到实战，破解亿级数据存储难题

没什么技术

已于 2025-02-22 23:48:04 修改

阅读量1.6k

点赞数 34

文章标签： java 分库分表

于 2025-02-22 23:43:19 首次发布

本文链接：https://blog.csdn.net/qq_62775328/article/details/145802852

版权

一、为什么需要分库分表？

随着业务规模的增长，单库单表逐渐暴露出性能瓶颈：

数据量过大：单表存储超过1亿条数据时，查询效率显著下降。
并发压力高：单一数据库的QPS（每秒查询数）难以支撑高并发场景。
维护困难：备份、恢复等运维操作耗时增加，影响业务连续性。

典型问题场景：

电商订单表日增百万数据，单表无法支撑。
用户行为日志表年增数十TB，存储成本飙升。
实时风控系统要求毫秒级响应，传统架构难以满足。

二、分库分表核心策略

1. 垂直拆分 vs 水平拆分

垂直拆分：

按业务拆分：将用户表、订单表等不同业务表拆分到不同数据库。
按字段拆分：将大字段（如JSON、BLOB）单独存储，减少主表压力。

水平拆分：

范围分片：按时间或ID范围划分数据（如按月份分表）。
哈希分片：通过哈希算法均匀分布数据（如按用户ID取模）。

2. 常用分片算法对比

算法	优点	缺点	适用场景
范围分片	易于扩容	数据分布不均	时间序列数据
哈希取模	数据分布均匀	扩容复杂	通用场景
一致性哈希	扩容影响小	实现复杂	动态扩容场景
地理位置分片	符合业务特性	需要业务适配	本地生活服务

三、实战：SpringBoot+ShardingSphere实现分库分表

场景：电商订单表水平分片（2库×2表）

1. 数据库规划

分片键：user_id（用户ID）
分片策略：user_id % 4
分布式ID：雪花算法生成唯一订单ID

2. ShardingSphere配置

spring:
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0: 
        url: jdbc:mysql://db0:3306/order
        username: root
        password: 123456
      ds1:
        url: jdbc:mysql://db1:3306/order
        username: root
        password: 123456

    rules:
      sharding:
        tables:
          order:
            actual-data-nodes: ds$->{0..1}.order_$->{0..1}
            database-strategy:
              standard:
                sharding-column: user_id
                sharding-algorithm-name: db-sharding
            table-strategy:
              standard:
                sharding-column: user_id
                sharding-algorithm-name: table-sharding
        
        sharding-algorithms:
          db-sharding:
            type: INLINE
            props:
              algorithm-expression: ds$->{user_id % 2}
          table-sharding:
            type: INLINE
            props:
              algorithm-expression: order_$->{user_id % 2}

三、生产环境进阶方案

1. 热点数据解决方案