数据库分库分表：从单库瓶颈到水平扩展的架构演进
数据库分库分表：从单库瓶颈到水平扩展的架构演进
一、单库性能天花板：当数据库成为系统最大瓶颈
关系型数据库在数据量和并发量增长到一定阶段后，必然遇到性能瓶颈。MySQL 单表数据量超过 5000 万行后，B+ 树索引层级增加，查询性能显著下降；单库的写入 QPS 上限约为 3000-5000（取决于硬件和索引复杂度），在高并发写入场景下远远不够；单机存储容量受限于磁盘大小，无法无限扩展。
更棘手的是，数据库的性能退化不是线性的——当活跃数据超过 Buffer Pool 容量时，查询从内存访问退化为磁盘 IO，性能可能骤降 10 倍以上。DDL 操作（加字段、建索引）在大表上执行时间以小时计，期间锁表导致业务不可用。分库分表是解决这些问题的根本手段，但它引入了分布式事务、跨库查询、数据迁移等新的复杂性。
二、分库分表核心机制：路由、分片与全局 ID 生成
分库分表的本质是将数据按照一定规则分散到多个数据库和表中，每个分片只承载部分数据和请求。下图展示了分库分表架构的核心组件：
flowchart TB App[应用服务] --> Proxy[分片代理 ShardingSphere-Proxy] Proxy --> Router[路由引擎 解析SQL确定分片] Router --> Shard0[分片0 db0.t_order_0] Router --> Shard1[分片1 db0.t_order_1] Router --> Shard2[分片2 db1.t_order_0] Router --> Shard3[分片3 db1.t_order_1] subgraph 全局ID生成 Snowflake[Snowflake 雪花算法] Leaf[Leaf 号段模式] end App --> Snowflake App --> Leaf subgraph 跨分片查询 Union[UNION 合并] Merge[内存归并排序] end Shard0 --> Union Shard1 --> Union Shard2 --> Union Shard3 --> Union Union --> Merge style Proxy fill:#ff9,stroke:#333 style Router fill:#9ff,stroke:#333 style Snowflake fill:#9f9,stroke:#3332.1 分片策略：哈希分片与范围分片
哈希分片（Hash Sharding）通过对分片键取模将数据均匀分散到各分片，优点是数据分布均匀、热点分散，缺点是范围查询需要扫描所有分片。范围分片（Range Sharding）按分片键的范围划分数据，优点是范围查询只需扫描相关分片，缺点是容易产生热点（最新数据集中在最后一个分片）。
生产环境中常用复合策略：以用户 ID 哈希分库保证数据均匀，以创建时间范围分表方便按时间查询和归档。
2.2 全局唯一 ID：分布式环境下的主键生成
分库分表后，数据库自增 ID 无法保证全局唯一。Snowflake 雪花算法是最常用的解决方案：64 位 ID 由时间戳 + 机器 ID + 序列号组成，既保证唯一性又保持趋势递增。Leaf 号段模式是美团的方案，通过预分配号段减少对发号中心的依赖，可用性更高。
2.3 跨分片查询：归并排序与二次查询
分库分表后，ORDER BY、LIMIT、GROUP BY 等操作需要在所有分片上执行，然后在代理层归并。这带来了两个问题：性能下降（所有分片都要查询）和内存消耗（代理层需要缓存所有结果）。深度分页（LIMIT 100000, 10）尤其严重，每个分片都需要返回前 100010 条记录。
三、生产级分库分表实现
3.1 ShardingSphere-JDBC 分片配置
# ShardingSphere-JDBC 分片规则配置 # 为什么用 ShardingSphere-JDBC 而非 Proxy 模式？ # 因为 JDBC 模式是应用内直连数据库，无中间件网络开销， # 性能比 Proxy 模式高 20%-30%，适合对延迟敏感的核心链路 mode: type: Standalone repository: type: JDBC dataSources: ds_0: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db0:3306/order_db_0 username: root password: ${DB_PASSWORD} # 为什么 HikariCP 连接池大小设为 20？ # 因为分库后每个数据源的连接数需求减少， # 4 个数据源 x 20 连接 = 80 总连接，足够支撑单实例 2000 QPS maximumPoolSize: 20 minimumIdle: 5 ds_1: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db1:3306/order_db_1 username: root password: ${DB_PASSWORD} maximumPoolSize: 20 minimumIdle: 5 rules: - !SHARDING tables: t_order: # 实际数据节点：2 个库 x 4 张表 = 8 个分片 actualDataNodes: ds_${0..1}.t_order_${0..3} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: order_table_mod databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: order_db_mod keyGenerateStrategy: column: id keyGeneratorName: snowflake shardingAlgorithms: order_db_mod: type: MOD props: sharding-count: 2 # 库数量 order_table_mod: type: MOD props: sharding-count: 4 # 表数量 keyGenerators: snowflake: type: SNOWFLAKE props: worker-id: 13.2 分布式事务：Seata AT 模式
/** * 跨库事务——Seata AT 模式 * 为什么用 AT 模式而非 TCC？ * 因为 AT 模式对业务代码侵入最小，只需加注解； * TCC 需要实现 Try/Confirm/Cancel 三个方法，改造成本高 * AT 模式的代价是性能（需要记录 undo_log）， * 但对于订单场景，正确性优先于性能 */ @Service public class OrderService { /** * 创建订单——跨库事务：订单库 + 库存库 * 为什么订单和库存要分库？ * 因为订单数据量大（亿级），库存数据量小但并发高， * 分库后可以独立扩展，避免互相影响 */ @GlobalTransactional(timeoutMills = 30000, name = "create-order") public OrderResult createOrder(CreateOrderRequest request) { // 步骤一：在订单库创建订单 // Seata AT 模式在此步骤前会自动记录 undo_log Order order = Order.builder() .userId(request.getUserId()) .skuId(request.getSkuId()) .quantity(request.getQuantity()) .status(OrderStatus.CREATED) .build(); orderMapper.insert(order); // 步骤二：在库存库扣减库存 // 为什么先创建订单再扣库存？ // 因为订单创建失败可以回滚，库存扣减失败也可以回滚， // 但如果先扣库存再创建订单，订单创建失败时库存需要回补， // 回补逻辑比回滚更复杂 int remain = stockMapper.deduct(request.getSkuId(), request.getQuantity()); if (remain < 0) { // 库存不足：抛出异常触发全局回滚 throw new BusinessException("库存不足"); } // 步骤三：在账户库扣减余额 accountMapper.deduct(request.getUserId(), request.getAmount()); return OrderResult.success(order.getId()); } }3.3 深度分页优化：游标分页
/** * 深度分页优化——基于游标的分页查询 * 为什么用游标分页而非 OFFSET 分页？ * 因为 OFFSET 100000 在分库分表场景下， * 每个分片都需要扫描前 100000 条记录， * 4 个分片 x 100000 = 400000 条记录在代理层归并， * 内存和 CPU 开销极大 */ @Repository public class OrderQueryRepository { /** * 游标分页：基于最后一条记录的 ID 继续查询 * 为什么游标分页更高效？ * 因为 WHERE id > last_id 只需扫描 last_id 之后的记录， * 不需要跳过前面的记录，IO 量与实际返回量成正比 */ public List<Order> queryByCursor(Long userId, Long lastId, int pageSize) { LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<Order>() .eq(Order::getUserId, userId) .gt(lastId != null, Order::getId, lastId) .orderByAsc(Order::getId) .last("LIMIT " + pageSize); return orderMapper.selectList(wrapper); } /** * 优化版 OFFSET 分页：二次查询法 * 为什么需要二次查询？ * 因为直接 OFFSET 在分片场景下每个分片都需要返回完整偏移量， * 二次查询法先获取各分片的最小 ID，再精确查询 */ public List<Order> queryByOffset(Long userId, int offset, int pageSize) { // 第一次查询：获取各分片在 offset 位置的 ID // 通过 ShardingSphere 的 hint 管理器指定分片 List<Order> firstRound = orderMapper.selectList( new LambdaQueryWrapper<Order>() .eq(Order::getUserId, userId) .orderByAsc(Order::getId) .last("LIMIT " + offset + ", " + pageSize) ); if (firstRound.isEmpty()) { return Collections.emptyList(); } // 获取最小 ID 作为真正的查询起点 Long minId = firstRound.stream() .map(Order::getId) .min(Long::compareTo) .orElse(0L); // 第二次查询：基于最小 ID 精确查询 return orderMapper.selectList( new LambdaQueryWrapper<Order>() .eq(Order::getUserId, userId) .ge(Order::getId, minId) .orderByAsc(Order::getId) .last("LIMIT " + pageSize) ); } }3.4 数据迁移：双写方案
/** * 数据迁移——双写 + 对比验证 * 为什么用双写而非停机迁移？ * 因为核心业务不能停机，双写可以在不停服的情况下 * 完成数据从旧库到新分片库的迁移 */ @Component @Slf4j public class DataMigrationService { private final AtomicBoolean migrationEnabled = new AtomicBoolean(false); /** * 双写开关：通过配置中心动态切换 * 为什么需要动态开关而非代码发布？ * 因为双写期间如果新库出现问题，需要立即关闭双写， * 代码发布流程太慢，配置中心可以秒级生效 */ @NacosValue(value = "${migration.dual-write.enabled:false}", autoRefreshed = true) public void setDualWriteEnabled(boolean enabled) { migrationEnabled.set(enabled); log.info("双写开关切换: {}", enabled); } /** * 双写逻辑：同时写入旧库和新分片库 */ @Transactional public void createOrderWithDualWrite(Order order) { // 写入旧库（主库） legacyOrderMapper.insert(order); // 双写：同时写入新分片库 if (migrationEnabled.get()) { try { shardingOrderMapper.insert(order); } catch (Exception e) { // 新库写入失败不影响主流程 // 为什么不回滚？因为旧库是权威数据源， // 新库写入失败通过异步对账修复 log.error("新库写入失败, orderId={}", order.getId(), e); migrationErrorRecorder.record(order.getId(), e.getMessage()); } } } /** * 数据一致性校验：对比旧库和新分片库的数据 * 为什么需要校验？因为双写期间新库可能写入失败， * 必须定期校验确保数据一致 */ @Scheduled(fixedDelay = 300000) // 每 5 分钟校验一次 public void verifyConsistency() { if (!migrationEnabled.get()) return; long lastCheckId = getLastCheckId(); List<Order> legacyOrders = legacyOrderMapper .selectByIdRange(lastCheckId, lastCheckId + 10000); for (Order legacy : legacyOrders) { Order sharding = shardingOrderMapper .selectById(legacy.getId()); if (sharding == null || !dataEquals(legacy, sharding)) { // 数据不一致：以旧库为准修复新库 log.warn("数据不一致, orderId={}", legacy.getId()); repairData(legacy); } } } }四、架构权衡：分库分表的代价与替代方案
跨库事务的代价：Seata AT 模式通过 undo_log 实现回滚，但全局锁的持有时间较长，在高并发场景下可能成为瓶颈。TCC 模式性能更好但改造成本高。最终一致性方案（消息队列 + 本地消息表）是最轻量的选择，但需要业务容忍短暂不一致。
跨库查询的代价：分库分表后，JOIN 查询、聚合查询、深度分页都变得复杂且低效。需要将跨库 JOIN 拆分为多次单库查询，在应用层组装。这增加了代码复杂度和网络开销。对于报表类复杂查询，建议使用独立的 OLAP 数据库（如 ClickHouse），而非在分片库上直接查询。
运维复杂度的代价：分库分表后，DDL 变更需要在所有分片上执行，数据迁移需要双写保障一致性，故障排查需要跨多个数据源。运维复杂度与分片数量正相关，建议分片数量不超过 16 个。
替代方案：在数据量尚未达到瓶颈时，可以考虑读写分离 + 缓存 + 归档（冷热分离）的组合方案，推迟分库分表。TiDB 等 NewSQL 数据库原生支持水平扩展，但迁移成本和生态兼容性需要评估。
适用边界：分库分表适用于单表数据量超过 5000 万行、写入 QPS 超过 5000 的场景。对于数据量在千万级以内的场景，优化索引 + 缓存 + 读写分离通常足够。
五、总结
分库分表是解决数据库性能瓶颈的根本手段，但引入了分布式事务、跨库查询、数据迁移等新的复杂性。核心实现要点：哈希分片保证数据均匀分布、Snowflake 生成全局唯一 ID、Seata AT 模式处理跨库事务、游标分页优化深度查询、双写方案保障数据迁移安全。落地路线上，建议先通过读写分离和缓存延缓分库需求，当单表数据量超过 5000 万时再启动分库分表。分片数量不宜过多，16 个以内为佳。分库分表是不可逆的架构决策，必须在充分评估数据增长趋势后再执行。