数据库分库分表实战：从拆分的时机到落地的完整路径

当单库单表的数据量增长到一定程度，索引失效、写入变慢、备份时间拉长等瓶颈接踵而至。分库分表是应对海量数据的经典手段，但拆分是有代价的——join 消失、事务边界变化、全局唯一 ID 成为问题。本文从"何时拆"讲起，给出完整的落地路径。

一、先回答：什么时候该拆

拆分的决策要基于真实数据，而不是焦虑：

单表数据量的经验红线：

• MySQL InnoDB 单表建议 2000 万行以内、单表 10GB 左右；
• 超过后索引 B+ 树层级加深，写入页分裂频繁，性能明显劣化。

可拆的信号：

• 单表持续超过 2000 万行且仍在高速增长；
• 热数据与冷数据混存导致缓存命中率低；
• 写入成为瓶颈（单机磁盘 IO、复制延迟）。

不拆的信号：

• 数据量平稳、查询命中率高；
• 没有明确的拆分键（业务上找不到稳定的分片维度）；
• 团队没有支撑分布式改造的运维能力。

最重要的建议：先做数据归档与冷热分离（把 3 年前的订单移到归档表/库），能解 80% 的"大表焦虑"，且几乎没有代价。

二、拆分维度的三种形态

| 形态 | 说明 | 典型场景 | |------|------|----------| | 垂直分库 | 按业务域拆库：订单库/用户库/商品库 | 微服务化 | | 垂直分表 | 大表拆列：把 text 大字段单独成表 | 文章表 content 独立 | | 水平分库分表 | 按分片键路由到 N 个库表 | 订单表按 user_id 分 64 表 |

水平拆分是主角，核心是选对分片键。

三、分片键的选择：成败的关键

3.1 三种分片算法

-- 1. 哈希取模：按 user_id % 64 路由
--    优点：数据均匀；缺点：无法范围扫描
WHERE user_id % 64 = 3

-- 2. 范围分片：按时间/ID 区间
--    优点：天然支持范围查询、扩容容易
--    缺点：热点集中在最新区间
WHERE created_at >= '2026-10-01'

-- 3. 一致性哈希：虚拟节点均匀分布
--    优点：扩容迁移数据量小
--    缺点：实现复杂

3.2 分片键的三个硬标准

1. 查询必经维度：90% 以上的查询都带这个条件（如"查某用户的订单" → user_id）；
2. 分布均匀：避免热门值倾斜（如单用户订单量极大则按其取模）；
3. 不可变性：分片键不可更新（一旦更新就跨分片搬家）。

四、落地架构：ShardingSphere 与中间件

4.1 应用内路由（ShardingSphere-JDBC）

# ShardingSphere 配置：orders 按 user_id 哈希分 8 库 × 8 表
rules:
  - !SHARDING
    tables:
      orders:
        actualDataNodes: ds_$->{0..7}.orders_$->{0..7}
        tableStrategy:
          standard:
            shardingColumn: user_id
            shardingAlgorithmName: orders_hash
    shardingAlgorithms:
      orders_hash:
        type: HASH_MOD
        props:
          sharding-count: 64

应用直连分片，SQL 透明路由，性能好、部署简单。

4.2 代理层（ShardingSphere-Proxy / MyCat）

独立部署一个中间件节点，应用像连单库一样连代理：

应用 → Proxy(3307) → 分片1/分片2/分片3

好处：应用零改造、便于集中管控；代价：多一跳网络、引入代理单点。

五、拆分后必须解决的三大问题

5.1 全局唯一 ID

自增 ID 在多分片下必然冲突，需全局唯一 ID 方案：

| 方案 | 特点 | |------|------| | UUID | 简单无序，索引碎片化严重 | | 雪花算法（Snowflake） | 有序递增、趋势升序，高并发友好 | | 号段模式（发号器） | DB 批量取号，可控性最好 | | Redis INCR 合并 | 简单但依赖 Redis 高可用 |

生产首选雪花算法或号段模式。

5.2 跨分片查询

• 禁止 join：数据建模阶段就按分片键反范式冗余（如订单表冗余用户昵称）；
• 全局聚合：先并行查各分片再合并排序（中间层做），或用 Elasticsearch 做宽表索引；
• 分页变味：跨分片的分页需要"取每片 N 页再内存合并"，深分页成本极高——业务上尽量用"游标翻页"替代页码翻页。

5.3 扩容

取模分片扩容要从 64 扩到 128，涉及全量数据迁移。提前规划容量（直接拆 256 表起步），或使用一致性哈希减少迁移量。

六、分库分表后的运维变化

# 备份从"一个库"变成"N 个库"
mysqldump --single-transaction orders_ds_0 > ds_0.sql
mysqldump --single-transaction orders_ds_1 > ds_1.sql

# 监控每分片的容量与延迟，防止倾斜

监控重点：各分片数据量差异、热点分片延迟、主从复制延迟（分片越多复制延迟放大越明显）。

结语

分库分表是"用复杂度换容量"的典型交易，一旦拆出去，join、事务、分页、扩容全部变成需要专门设计的工程问题。正确的姿势是慢决策、快执行：先归档冷数据，再确认分片键，再选路由方式，最后才动手拆。同时记住，拆分不是终点——配合归档、缓存、只读副本等方案，才能让分布式数据库体系长期健康运转。