分库分表的取舍

大数据量下采用水平分表的缺点

1. 跨表查询复杂性与性能下降

• 问题：当查询需要跨多个分表（如 JOIN 操作或跨分表的聚合查询）时，需合并多个表的结果，导致查询逻辑复杂化，且性能显著下降。
  • 原因：水平分表后，数据分散在不同表或不同数据库中，传统的 SQL 语句无法直接关联这些分表，需要应用层或中间件处理，增加了网络开销和计算复杂度。
  • 示例：若用户订单表按 用户ID 分表，查询某用户的历史订单需遍历所有分表，或需应用层合并结果。

2. 数据分布不均衡

• 问题：若分表规则设计不合理（如按时间范围或固定区间分表），可能导致某些分表数据量远超其他分表，引发资源不均衡。
  • 原因：
    • 热点分表：例如按时间范围分表时，新数据可能集中在最新分表，导致写入压力集中（如交易流水表）。
    • 哈希分表的局限性：若业务数据天然存在分布不均（如某些用户数据量远超其他用户），哈希分表可能无法完全避免倾斜。
  • 影响：部分分表成为性能瓶颈，甚至引发单点故障。

3. 分布式事务与一致性问题

• 问题：跨分表的事务操作难以保证原子性和一致性。
  • 原因：
    • 水平分表后，若数据分布在不同数据库或节点上，需依赖分布式事务（如两阶段提交，2PC），但会显著增加延迟和复杂度。
    • MySQL 本身不支持跨分表的事务，需通过应用层或中间件实现，可能导致性能下降或数据不一致风险。
  • 示例：转账操作涉及两个用户的分表，若其中一个分表操作失败，需手动回滚，容易引发数据不一致。

4. 扩展性受限

• 问题：扩容或调整分表策略时面临挑战。
  • 哈希分表的扩展问题：
    • 若分表数量增加（如从3个分表扩展到4个），需重新计算所有数据的哈希值并迁移数据，导致停机或性能下降（如[5]中一致性哈希的复杂性）。
  • 范围分表的扩展问题：
    • 新增分表需定义新的范围，但历史数据无法自动迁移，可能需手动调整查询逻辑。

5. 查询条件限制与索引管理复杂

• 问题：
  • 查询条件依赖分片键：若查询条件不包含分片键（如按 订单金额 查询），需全表扫描所有分表，性能极差。
  • 索引维护成本高：每个分表需独立维护索引，索引碎片化和维护成本成倍增加。
• 示例：若分片键是 用户ID，但业务需按 商品ID 查询，则需扫描所有分表。

6. 数据迁移与维护成本高

• 问题：
  • 初始分表成本：将原有大表拆分为多个分表并迁移数据，需停机或复杂的数据迁移工具支持。
  • 后期维护复杂：备份、恢复、数据迁移、索引优化等操作需针对每个分表单独执行，管理成本显著上升（如[3]提到的“数据库维护复杂”）。

7. 业务逻辑复杂度增加

• 问题：
  • 路由逻辑复杂：需在应用层或中间件实现分片键到具体分表的映射（如哈希计算、范围判断）。
  • 中间表映射的缺陷：若依赖中间表记录分片规则，可能引发中间表数据膨胀或查询性能下降（如[5]提到的中间表映射策略的缺点）。

总结

水平分表在解决单表数据量过大、提升查询性能和扩展性方面有显著优势，但其缺点主要集中在跨分片操作复杂性、数据分布不均、事务一致性挑战、扩展性限制以及维护成本上升。因此，在实施水平分表时需谨慎设计分片策略（如选择合适的分片键、采用一致性哈希等），并结合垂直分表、缓存、读写分离等方案综合优化系统架构。

shardingJdbc分片策略

ShardingJDBC的分片策略是其核心功能之一，用于实现数据分库分表的路由逻辑。根据知识库中的信息，以下是 分片策略的分类、特点及使用场景 的详细说明：

1. 标准分片策略（Standard）

• 定义：适用于单一分片键的场景，支持 精确查询（=, IN）和 范围查询（BETWEEN, >, < 等）。

• 配置要求

  ：

  • 必须指定 分片键（shardingColumn）和 分片算法名称（shardingAlgorithmName）。
  • 支持两种算法：
    • 精准分片算法（PreciseShardingAlgorithm）：处理 = 和 IN 的查询，必须实现。
    • 范围分片算法（RangeShardingAlgorithm）：处理 BETWEEN 等范围查询，可选。若未配置，范围查询会全库扫描。

• 适用场景

  ：

  • 单一字段分片（如 order_id 分库分表）。
  • 需要支持范围查询的场景（如按时间范围分表）。

• 配置示例

  （YAML）：

  yaml

  深色版本

  spring:
    shardingsphere:
      rules:
        sharding:
          tables:
            t_order:
              actual-data-nodes: db$->{0..1}.t_order_$->{0..10}
              databaseStrategy:
                standard:
                  shardingColumn: order_id
                  shardingAlgorithmName: db-inline
              tableStrategy:
                standard:
                  shardingColumn: order_id
                  shardingAlgorithmName: table-inline
  

2. 复合分片策略（Complex）

• 定义：支持 多分片键 的组合分片，适用于跨表关联查询的场景。

• 特点

  ：

  • 分片键为多个字段（如 user_id 和 order_time）。
  • 需要开发者自定义分片算法（ComplexShardingAlgorithm），直接处理分片键的组合逻辑。
  • 适用于绑定表（如 t_order 和 t_order_item）的关联查询，避免笛卡尔积。

• 适用场景

  ：

  • 需要多条件联合分片的复杂查询（如 user_id 和 order_time）。
  • 绑定表的跨表关联查询。

• 注意事项

  ：

  • 复合分片会增加路由复杂度，需确保分片键组合能均匀分布数据。
  • 需自行实现分片算法逻辑。

3. 行表达式分片策略（Inline）

• 定义：通过 Groovy表达式 简化分片配置，无需编写Java代码。

• 特点

  ：

  • 支持单分片键，仅支持 = 和 IN 的精确查询（不支持范围查询）。
  • 表达式语法示例：t_order_${order_id % 4}。

• 适用场景

  ：

  • 简单的分片规则（如取模分表）。
  • 避免编写复杂算法的场景。

• 配置示例

  （YAML）：

  yaml

  深色版本

  spring:
    shardingsphere:
      rules:
        sharding:
          tables:
            t_order:
              actual-data-nodes: db0.t_order_$->{0..3}
              tableStrategy:
                inline:
                  shardingColumn: order_id
                  algorithmExpression: t_order_${order_id % 4}
  

4. Hint分片策略（Hint）

• 定义：通过 代码提示 指定分片目标，无需依赖SQL解析。

• 特点

  ：

  • 适用于无法通过SQL解析获取分片键的场景（如动态路由）。
  • 需配合 HintManager API 显式指定分片值。

• 适用场景

  ：

  • 需要动态指定分片的场景（如根据用户ID路由到特定库表）。
  • 避免SQL解析限制的场景（如SQL中包含函数或复杂表达式）。

• 使用示例

  （Java代码）：

  java

  深色版本

  try (Connection conn = dataSource.getConnection()) {
      HintManager hintManager = HintManager.getInstance();
      hintManager.addDatabaseShardingValue("t_order", "user_id", 1001);
      // 执行SQL
  }
  

5. 不分片策略（None）

• 定义：指定某张表或某个操作 不分片，数据全部存储在单个库表中。

• 适用场景

  ：

  • 广播表（如字典表、配置表）。
  • 特定操作需要跨分片聚合时，需将结果汇总到单表。

• 配置示例

  （YAML）：

  yaml

  深色版本

  spring:
    shardingsphere:
      rules:
        sharding:
          tables:
            t_dict:
              databaseStrategy:
                none: {}
              tableStrategy:
                none: {}
  

分片策略选择建议

1. 单分片键 + 精准/范围查询 → 标准分片策略。
2. 多分片键组合分片 → 复合分片策略。
3. 简单规则（如取模） → 行表达式分片策略。
4. 动态路由或复杂场景 → Hint分片策略。
5. 广播表或无需分片的表 → 不分片策略。

注意事项

• 范围查询风险：若标准分片策略未配置范围分片算法，范围查询会全库扫描，性能极差。
• 复合分片复杂度：需确保多分片键的组合能均匀分布数据，避免热点。
• SQL兼容性：某些SQL函数或操作符可能导致分片失效，需避免使用或结合Hint策略。

shardingJdbc和shardingProxy的区别

1. 架构与部署方式

2. 侵入性与透明性

3. 性能对比

4. 配置与管理

5. 功能支持

6. 适用场景

7. 配置示例对比

Sharding-JDBC（YAML配置）

spring:
  shardingsphere:
    datasource:
      names: ds0, ds1
      ds0:
        url: jdbc:mysql://localhost:3306/ds0
        username: root
        password: root
        driver-class-name: com.mysql.cj.jdbc.Driver
    rules:
      sharding:
        tables:
          t_order:
            actual-data-nodes: ds$->{0..1}.t_order_$->{0..2}
            table-strategy:
              standard:
                sharding-column: order_id
                sharding-algorithm-name: t_order-inline
        sharding-algorithms:
          t_order-inline:
            type: INLINE
            props:
              algorithm-expression: t_order_$->{order_id % 3}

Sharding-Proxy（server.yaml配置）

schema-name: sharding_db
dataSources:
  ds0:
    url: jdbc:mysql://localhost:3306/ds0
    username: root
    password: root
    connectionTimeoutSeconds: 30
    idleTimeoutSeconds: 60
    maxLifetimeSeconds: 1800
    maxPoolSize: 50
shardingRule:
  tables:
    t_order:
      actualDataNodes: ds$->{0..1}.t_order_$->{0..2}
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: t_order_inline
  shardingAlgorithms:
    t_order_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_$->{order_id % 3}

总结选择建议

• 选Sharding-JDBC：

  • 纯Java应用，追求高性能和低延迟。
  • 需要与业务代码深度集成，如Spring Boot项目。
  • 对分片规则的动态调整需求较低，或能接受重启应用。

• 选Sharding-Proxy：

  • 多语言应用或需要DBA直接管理分片规则。
  • 需要动态调整分片策略且无需重启服务。
  • 需要通过工具（如Navicat、MySQL Workbench）直接操作分片数据。