MySQL分库分表方案实战：拆分策略、中间件选型与数据迁移

分库分表是MySQL应对数据量增长的最后手段，不是第一选择。单表数据量过亿、单库写入QPS持续攀升、单库连接数打满，这三个信号出现时，才需要考虑水平拆分。本文介绍分库分表的拆分维度、中间件选型、数据迁移与踩坑要点，重点放在方案设计，帮助在动手前把边界想清楚。

分库分表前先做的三件事

拆分是重资产改造，动手前先排查三个低成本方案：读写分离，把只读流量压到从库；冷热数据分离，归档半年以上数据，主表只留热数据；大字段拆分，把BLOB/TEXT等不常查询的列移到扩展表。多数团队的真实瓶颈不在数据量，而在慢查询和索引设计，先把这三步做完再评估是否真的需要分库分表。

拆分维度设计：水平分表与垂直分库

水平拆分按业务主键路由，单表数据量可控制在千万级以内。路由键选择决定一切：订单场景按用户ID或订单ID分片，账务场景按账号分片，日志场景按时间分片。垂直分库按业务域拆分，把用户、订单、商品拆成独立库，核心是让跨域查询尽量少。常见路由规则：

# 按用户ID取模分4库8表
def route(user_id):
    db = user_id % 4
    table = (user_id // 4) % 8
    return db, table

# 按时间分表：order_202609
def route_by_time(ts):
    return "order_" + ts.strftime("%Y%m")

取模路由实现简单，但扩容需要迁移数据；时间分表适合流水类数据，冷热天然分层。按业务特点选，不要混用两种路由到同一张表。

分库分表中间件：ShardingSphere与MyCat对比

中间件选型直接影响改造成本。ShardingSphere-JDBC以客户端SDK方式工作，应用直接连数据库，无需独立部署，支持分片、读写分离、分布式事务（基于Seata），Java生态友好；MyCat以代理模式部署在应用与数据库之间，对应用透明，适合多语言场景，但增加一跳网络开销，运维组件更多。中小团队建议优先ShardingSphere-JDBC，配置改动集中在数据源与分片规则上：

spring:
  shardingsphere:
    datasource:
      names: ds0,ds1
      ds0:
        type: com.zaxxer.hikari.HikariDataSource
        url: jdbc:mysql://192.168.1.10:3306/order_db_0
      ds1:
        type: com.zaxxer.hikari.HikariDataSource
        url: jdbc:mysql://192.168.1.11:3306/order_db_1
    rules:
      sharding:
        tables:
          t_order:
            actual-data-nodes: ds$->{0..1}.t_order_$->{0..7}
            database-strategy:
              standard:
                sharding-column: user_id
                sharding-algorithm-name: db_inline
            table-strategy:
              standard:
                sharding-column: user_id
                sharding-algorithm-name: table_inline
    props:
      sql-show: true

配置以所用版本官方文档为准，版本间语法差异较大。

数据迁移方案：停机切换与双写方案

存量数据迁移是分库分表项目最危险的一环。小数据量（百万级）可用停机切换：停写、导出、按新路由灌入、校验、切流。大数据量用双写方案：新库同步写，历史数据批量迁移，对账校验后切读流量。双写期间要处理一个难点：旧库自增主键与新库路由不兼容，业务表的主键需要重新规划，常用方案是发号器（雪花ID或号段模式）统一生成主键。

分库分表后的查询与事务边界

拆分后最直观的变化是查询受限：无分片键的查询要广播到所有分片再聚合，性能差且容易被误用。应对方法：建全局索引表（如按手机号维度的用户映射表）；把跨片查询改成多次点查再在应用层聚合；对必须全量扫描的报表需求走离线数仓，别在生产库上跑。分布式事务用Seata AT模式，事务边界尽量控制在单分片内，跨分片事务过多说明拆分维度设计有问题。最后记住一点：分库分表是架构决策，上线后要配套监控分片倾斜度、慢SQL、中间件代理指标，任何分片数据不均匀都要及时发现。