数据库水平拆分与跨库查询方案-源码库

数据库水平拆分与跨库查询方案：从单库瓶颈到分布式架构实战

记得第一次遇到数据库性能瓶颈时，我盯着监控图上持续走高的CPU使用率，意识到单机数据库已经无法支撑业务的高速增长。经过多次实战，我总结出水平拆分（分库分表）这套解决方案，今天就来分享具体的实施步骤和跨库查询的处理技巧。

为什么需要水平拆分？

当单表数据量突破千万级别，或者单个数据库实例无法承受高并发读写时，水平拆分就成了必然选择。我经历过的最典型场景是用户表——当用户数达到5000万时，简单的查询都要耗时数秒，更不用说复杂的联表操作了。

水平拆分实战步骤

第一步：选择合适的分片键

分片键的选择直接影响拆分效果。以用户表为例，我通常选择user_id作为分片键，这样可以保证同一个用户的数据落在同一个分片上：

-- 原始用户表结构
CREATE TABLE users (
    user_id BIGINT PRIMARY KEY,
    username VARCHAR(50),
    email VARCHAR(100),
    created_at TIMESTAMP
);

踩坑提示：不要选择分布不均匀的字段作为分片键，比如性别字段，会导致数据倾斜。

第二步：确定分片策略

我常用的两种分片策略：

范围分片：按user_id范围划分，比如0-1000万在分片1，1000万-2000万在分片2
哈希分片：对user_id取模，确保数据均匀分布

// Java示例：哈希分片算法
public int getShardIndex(long userId, int totalShards) {
    return (int) (userId % totalShards);
}

第三步：实现跨库查询方案

这是最考验技术功力的环节。我推荐三种方案：

方案一：客户端分片

在应用层实现路由逻辑，这是我早期项目常用的方式：

// 查询特定用户信息
public User getUserById(long userId) {
    int shardIndex = getShardIndex(userId, SHARD_COUNT);
    String dataSourceName = "ds_" + shardIndex;
    // 从对应的数据源执行查询
    return userMapper.getUserById(dataSourceName, userId);
}

实战经验：这种方式简单直接，但需要在业务代码中维护数据源路由逻辑。

方案二：使用中间件

对于复杂查询，我推荐使用ShardingSphere这类中间件：

# ShardingSphere配置示例
sharding:
  tables:
    users:
      actualDataNodes: ds_${0..1}.users_${0..1}
      tableStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: user_hash
      keyGenerateStrategy:
        column: user_id
        keyGeneratorName: snowflake

方案三：异步聚合查询

对于需要跨多个分片的查询，我采用并行查询再聚合的方式：

// 并行查询所有分片
public List searchUsers(String keyword) {
    List>> futures = new ArrayList<>();
    
    for (int i = 0; i < SHARD_COUNT; i++) {
        futures.add(CompletableFuture.supplyAsync(() -> 
            userMapper.searchUsers("ds_" + i, keyword)
        ));
    }
    
    return futures.stream()
        .map(CompletableFuture::join)
        .flatMap(List::stream)
        .collect(Collectors.toList());
}