当前位置：首页 > news >正文

数据库分库分表从理论到实战

news 来源：原创 2025/6/9 23:07:39

1.分库分表基础理论

1.1 分库分表基本概念

定义：分库分表是一种将单一数据库中的数据分散存储到多个数据库或表中的技术方案，其核心思想是通过"分而治之"的方式解决数据库性能瓶颈问题。
分库：将表按业务或数据量拆分到不同数据库中。是指将表按业务或数据量拆分到不同数据库中。例如，一个电商系统可以将用户数据、订单数据和商品数据分别存储在不同的数据库中
。这种拆分可以是物理上的，即不同的数据库实例运行在不同的服务器上；也可以是逻辑上的，即同一个数据库实例中的不同数据库。
分表：将单表数据按规则拆分到多个表中。就是将单表数据按规则拆分到多个表中。例如，一个包含10亿条用户数据的表可以拆分为100个表，每个表存储1000万条数据。分表可以是水平拆分（按行拆分）或垂直拆分（按列拆分）。
核心目的：解决单库单表性能瓶颈，提高系统扩展性和可用性，突破单机存储限制，实现业务模块解耦

1.2 为什么需要分库分表

单库性能瓶颈：这是推动分库分表的最大因素。当并发请求量达到一定规模时，单台数据库服务器无法满足性能需求。例如，MySQL默认的最大连接数为151，在电商大促期间可能远远不够。接数、CPU、内存、磁盘IO等资源限制。
单表数据量过大：会导致B+树层级变高，查询性能下降。MySQL的InnoDB引擎使用B+树索引结构，当单表数据超过500万行时，索引层级可能从3层增加到4层，导致查询时需要多一次磁盘IO。此外，大数据量表也会导致备份、维护和DDL操作时间过长。
业务发展需求：微服务架构演进，业务模块解耦。随着微服务架构的流行，业务模块需要独立部署和扩展，不同业务模块对数据库的要求（如事务隔离级别、读写比例等）可能不同，分库可以实现专库专用。单台服务器的存储容量有限，而业务数据可能持续增长，分库分表提供了理论上无限的存储扩展能力。

1.3 分库分表适用场景

单表数据量接近或超过500万行
数据库备份/维护时间过长
高并发场景下数据库连接数不足
业务模块需要独立部署和扩展

2.分库分表核心策略

2.1 垂直拆分

垂直分库：按业务模块拆分到不同库
- 示例：用户库、订单库、商品库分离
- 优点：业务解耦，专库专用，减少单库压力，提升性能，便于微服务架构开发设计
- 例如：在电商系统中：

用户库(user_db)：存储用户注册、登录、个人信息等数据

订单库(order_db)：存储订单、支付、物流等数据

商品库(product_db)：存储商品信息、库存、类目等数据

垂直分表：按字段拆分大表，将不常用或大字段拆分到扩展表中。
- 示例：将用户表拆分为基础信息表和扩展信息表
- 优点：减少IO，提高缓存效率
- 例如：拆分用户表：

user_basic：用户ID、用户名、密码、手机号等核心字段

user_extend：个人简介、兴趣爱好、教育经历等扩展字段

2.2 水平拆分

水平拆分是指按照某种规则将同一表的数据分散到多个库或表中，包括水平分库和水平分表两种方式：

水平分库：同一表数据分散到不同库
- 示例：订单表按订单ID哈希分到多个库。例如，订单表可以按订单ID哈希值分散到10个库中，每个库存储一部分订单数据。这种方式通常需要配合分布式ID生成策略，确保ID的唯一性和有序性。
水平分表：单表数据分散到多个具有相同表结构的表。
- 示例：订单表可以拆分为order_0到order_9共10个表，每个表存储订单ID以特定数字结尾的记录。
优点：解决单表数据量过大问题，提升高并发处理能力（不同分片可并行处理），数据分布均匀，避免热点问题。

2.3 混合拆分策略

先垂直后水平的分层拆分
按业务垂直分库+按数据量水平分表

例如电商系统：

先垂直拆分为用户库、订单库、商品库等
对订单库中的订单表，再水平拆分为order_0到order_9
对用户库中的用户表，按用户ID范围拆分为user_0到user_4

这种混合策略结合了垂直拆分和水平拆分的优点，既能实现业务解耦，又能解决单表数据量过大的问题。

3.分片算法与路由机制

3.1 常用分片算法

哈希分片：取模(hash(key)%N)或一致性哈希
- 优点：数据分布均匀
- 缺点：扩容需数据迁移
范围分片：按ID或时间范围划分
- 优点：便于范围查询
- 缺点：可能产生热点
目录分片：维护分片映射表
- 优点：灵活度高
- 缺点：需额外维护映射表

3.2 分片键选择原则

分片键的选择直接影响分库分表的效果，应遵循以下原则：

选择查询频率高的字段：如订单系统常用order_id查询，则应选择order_id作为分片键。
避免选择有明显倾斜的字段：如按性别分片会导致数据分布不均。
考虑业务增长模式：如按时间分片需考虑数据随时间增长的均匀性。
常用分片键包括：用户ID、订单ID、时间戳等。

3.3 分片路由设计

客户端路由(Sharding-JDBC)

// Sharding-JDBC示例配置
spring.shardingsphere.datasource.names=ds0,ds1
spring.shardingsphere.sharding.tables.t_order.actual-data-nodes=ds$->{0..1}.t_order_$->{0..15}
spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.sharding-column=order_id
spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.algorithm-expression=t_order_$->{order_id % 16}

代理层路由(MyCat/Sharding-Proxy) ：通过中间件代理完成路由。这种方式对应用透明，但多一层网络开销。
分布式ID生成方案：分库分表需要全局唯一的ID生成方案

雪花算法(Snowflake)：时间戳+机器ID+序列号

数据库号段：批量获取ID段，减少数据库访问

UUID：简单但无序，不适合作为数据库主键

雪花算法示例：

// 雪花算法ID生成示例
public class SnowflakeIdGenerator {private static final long START_TIMESTAMP = 1480166465631L;private static final long SEQUENCE_BITS = 12L;private static final long WORKER_ID_BITS = 5L;private static final long MAX_WORKER_ID = -1L ^ (-1L << WORKER_ID_BITS);private long workerId;private long sequence = 0L;private long lastTimestamp = -1L;public synchronized long nextId() {long timestamp = timeGen();if (timestamp < lastTimestamp) {// 处理时钟回拨throw new RuntimeException("Clock moved backwards");}if (lastTimestamp == timestamp) {sequence = (sequence + 1) & ((1 << SEQUENCE_BITS) - 1);if (sequence == 0) {timestamp = tilNextMillis(lastTimestamp);}} else {sequence = 0L;}lastTimestamp = timestamp;return ((timestamp - START_TIMESTAMP) << (WORKER_ID_BITS + SEQUENCE_BITS))| (workerId << SEQUENCE_BITS)| sequence;}
}