数据库分库分表策略与数据迁移方案-源码库

数据库分库分表策略与数据迁移方案：从单机到分布式的平滑演进

大家好，我是33blog的技术博主。今天想和大家聊聊我在实际项目中实施数据库分库分表时积累的经验。记得第一次面对单机数据库性能瓶颈时，那种“数据库快要撑不住了”的焦虑感至今记忆犹新。经过多个项目的实践，我总结出了一套相对成熟的分库分表策略和数据迁移方案，希望能帮助大家少走弯路。

为什么要分库分表？

当我们的业务数据量达到千万级别，或者并发请求量让单机数据库不堪重负时，分库分表就成了必然选择。我经历过最典型的情况是：某个核心业务表的查询响应时间从几十毫秒飙升到几秒，数据库CPU经常跑满。这时候，分库分表不再是“要不要做”的问题，而是“怎么做”的问题。

分库分表策略选择

根据我的经验，策略选择主要考虑数据特性和业务场景：

1. 水平分表 – 按某个字段（如用户ID）将数据分布到多个表中：

-- 例如按用户ID取模分表
CREATE TABLE user_0 (id BIGINT, name VARCHAR(50), ...);
CREATE TABLE user_1 (id BIGINT, name VARCHAR(50), ...);
-- 以此类推创建user_2到user_15

2. 垂直分库 – 将不同业务模块的数据拆分到不同数据库：

-- 用户相关表放在user_db
-- 订单相关表放在order_db  
-- 商品相关表放在product_db

踩坑提示：我最初曾过度设计，分了太多表，导致维护成本激增。建议根据实际数据量和增长预期合理规划分表数量。

数据迁移实战步骤

数据迁移是整个过程中最需要谨慎的环节，我通常采用双写方案来保证数据安全：

步骤1：准备工作

# 创建新的分库分表结构
mysql -h new_db_host -u root -p < create_sharding_schema.sql

# 备份原数据库
mysqldump -h old_db_host -u root -p original_db > backup.sql

步骤2：开启双写

在应用层同时写入新旧两个数据库，这是保证数据不丢失的关键：

// Java示例代码
public void saveUser(User user) {
    // 写入原数据库
    oldUserDAO.insert(user);
    
    // 根据分片键计算应该写入哪个分表
    int shard = user.getId() % 16;
    newUserDAO.insertToShard(user, shard);
}

步骤3：数据迁移

# 使用数据同步工具进行全量迁移
./data_sync_tool --source old_db --target new_db --table users

步骤4：数据校验

-- 对比新旧数据是否一致
SELECT COUNT(*) FROM old_db.users;
SELECT SUM(COUNT(*)) FROM new_db.user_0,...,new_db.user_15;

步骤5：切换读流量

先切部分读流量到新库，观察一段时间没问题后再全部切换。

步骤6：停用旧库

确认新库稳定运行后，停用对旧库的写入。

遇到的坑与解决方案

在实际迁移过程中，我遇到了几个典型问题：

问题1：分布式ID生成

分库分表后，自增ID不再适用。我推荐使用雪花算法：

public class SnowflakeIdGenerator {
    // 实现雪花算法生成分布式ID
    public long nextId() {
        // 具体实现代码
    }
}

问题2：跨分片查询

分表后，原本简单的查询可能变得复杂。我的做法是：

// 对于需要跨分片查询的场景，使用中间件或手动聚合
public List queryUsersByName(String name) {
    List result = new ArrayList<>();
    for (int i = 0; i < 16; i++) {
        result.addAll(userDAO.queryFromShard(name, i));
    }
    return result;
}