分库分表实战：从策略设计到生产部署全解析

1. 分库分表部署前的战略规划与准备工作

1.1 现状评估与决策制定

当数据库单表数据量突破500万行时，性能瓶颈会逐渐显现。我在某电商平台项目中，曾遇到订单表达到800万行后，查询响应时间从200ms骤增至2s以上的情况。这时候就需要进行全面的现状评估：

性能瓶颈分析的三个关键维度：

1. 资源指标监控：通过Prometheus采集QPS、TPS、连接数等指标。我们发现高峰期QPS达到5000时，CPU利用率持续在90%以上
2. 慢查询分析：使用pt-query-digest工具发现，超过2s的查询中有80%是订单分页查询
3. 容量预测：基于过去12个月数据，订单表每月增长约60万行，预计6个月后将突破1000万行

重要提示：不要仅凭直觉判断是否需要分库分表，必须用数据说话。我们曾有个项目误判了瓶颈，实际是缺少索引导致的问题。

1.2 分库分表策略设计

水平拆分与垂直拆分的抉择：

• 用户画像系统采用垂直拆分，将用户基础信息、行为数据、标签数据分离到不同库
• 订单系统采用水平拆分，按用户ID哈希分片

分片键选择的实战经验：

• 好选择：用户ID（查询频次高、离散性好）
• 次优选择：订单创建时间（存在热点问题）
• 避免选择：订单状态字段（区分度低）

我们设计的哈希分片算法包含这些优化：

java复制// 改进版分片算法，解决传统哈希的重新分片问题
public static int calculateShard(String shardKey, int shardCount) {
    // 使用CRC32替代hashCode，分布更均匀
    CRC32 crc32 = new CRC32();
    crc32.update(shardKey.getBytes());
    long hash = crc32.getValue();
    
    // 引入虚拟节点，减少扩容时的数据迁移量
    int virtualNodes = 160; // 每个物理节点对应160个虚拟节点
    return (int)(hash % (shardCount * virtualNodes) / virtualNodes);
}

1.3 技术选型与工具准备

中间件选型对比表：