ShardingSphere分库分表实战：数据分片与分布式主键配置方案

分库分表是把单库单表拆成多库多表，解决数据量过大导致的写入、查询、索引膨胀问题。Apache ShardingSphere是应用最广的分库分表中间件，把分片逻辑收敛在数据访问层。本文用实际配置说明ShardingSphere的分片规则、分布式主键与扩容迁移实操。

分库分表的前提：单表数据量到什么阈值要拆

先评估是否真的需要拆分。MySQL单表建议不超过2000万行，超过后索引膨胀、写入性能、维护成本都明显上升。但要综合考虑磁盘、IO、业务模式：如果大量访问集中在最近数据，可以按时间归档清理；只有业务模型本身是水平扩展的（如订单按用户拆），才适合分库分表。分库分表会引入跨库查询、分布式事务、全局ID等复杂度，数据量没到位时不要提前拆。

2. ShardingSphere分片方式：水平分片配置示例

ShardingSphere-JDBC以jar方式嵌入应用，直接连数据源，适合Java后端。下面以订单表t_order为例，按order_id取模分4库（ds0~ds3），每库4表（t_order_0~t_order_3）：

spring:
  shardingsphere:
    datasource:
      names: ds0,ds1,ds2,ds3
      ds0:
        type: com.zaxxer.hikari.HikariDataSource
        url: jdbc:mysql://172.16.0.10:3306/ds0?useSSL=false
        username: order_rw
        password: '***'
      # ds1/ds2/ds3 同理，指向不同实例
    rules:
      sharding:
        tables:
          t_order:
            actual-data-nodes: ds$->{0..3}.t_order_$->{0..3}
            table-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: order_table_inline
            key-generate-strategy:
              column: order_id
              key-generator-name: snowflake
        sharding-algorithms:
          order_table_inline:
            type: INLINE
            props:
              algorithm-expression: t_order_$->{order_id % 4}
          db_inline:
            type: INLINE
            props:
              algorithm-expression: ds$->{order_id % 4}
        key-generators:
          snowflake:
            type: SNOWFLAKE
    props:
      sql-show: true

分片算法INLINE通过表达式计算分库分表位置，order_id%4对应数据节点。按用户维度拆表用user_id取模，按时间维度拆表用YEAR_MONTH。分片键必须出现在SQL的WHERE条件中，否则全路由扫描，性能退化。

3. 分布式主键：雪花算法与分布式ID生成

分库后数据库自增主键冲突，需要全局唯一主键。ShardingSphere内置雪花算法（Snowflake）：64位ID由时间戳+机器ID+序列号组成，趋势递增。对有序性要求更高的场景可用UID自定义生成（时间+随机），不用中间件的直接用应用层发号器（如美团Leaf、百度UidGenerator）。主键选型要确保：全局唯一、趋势递增（对索引友好）、无序随机（避免热点）。

4. 分库分表后的SQL限制与兼容方案

分片后，以下SQL会受到限制：不加分片键的查询会路由到所有分片，性能差，必须加分片键或创建全局索引表；跨分片聚合（COUNT/SUM/AVG）会被ShardingSphere合并执行，但跨分片JOIN支持有限；分布式事务推荐用Seata或最终一致方案。折中：核心大表按分片键分片，关联的小表/字典表保留单库单表，用广播表同步；中间表用绑定表组减少JOIN。

5. 数据迁移：存量数据如何迁入分片

线上分库分表常见于存量表已很大。迁移方案：先用离线工具（如pt-archiver、mysqldump+load）把存量数据分批迁到分库分表结构中，按分片键计算目标库表；迁移期间业务停写，用双写或binlog订阅（如Canal）做增量补偿。建议按主键分段，先小范围验证映射，再全量推进，迁移完成后用SQL校验记录总数与分布一致性，最后切换读写路由。

6. 分库分表后的运维与监控要点

分库分表不改变数据库运维本质，但节点数变多，监控成本增加。需要覆盖：每个分库的连接数、QPS、慢查询，各分片的容量增长，分片键分布均匀度（热点分片检测）。ShardingSphere自带审计日志与SQL解析，可以把慢SQL、分片统计上报到监控体系；分布式事务与跨库查询要设计在应用层，而不是数据库层。

分库分表不是银弹。它解决的是单库数据量瓶颈，同时引入分片键选择、跨库查询、分布式事务、数据迁移多道坎。技术判断：先在垂直维度拆库（把不同业务库拆开）、读写分离与归档，把水平分片作为最后手段。若业务模型本身适合分片（订单、消息等强分片键场景），则ShardingSphere是当前成熟度最高、文档最全的方案之一。