Sharding是什么？

Sharding（分片）就像把一整个图书馆的书拆开放到多个小房间，每个房间只存一部分书。这样找书的人不用挤在一个大厅里翻找，效率更高。

技术定义：
把一个大数据库拆分成多个小数据库（分片），分散到不同服务器上，解决单台服务器性能不足的问题。比如原本一个数据库存10亿条用户数据，拆成10个库，每个存1亿条 。
场景类比：
图书馆分房间：按书的类型（科技、文学）或首字母分房间。
电商分订单：按用户ID把订单分到不同数据库，避免双十一订单挤爆服务器。

Sharding有什么用？

解决性能瓶颈

问题：单台数据库处理能力有限，数据量大时查询慢、写入卡顿。
方案：通过分片分散压力。例如，每秒处理10万订单的电商系统，分到10个库后，每个库只需处理1万。

提高扩展性

灵活扩容：数据增长时，只需加新分片，不用整体升级服务器。比如从10个分片扩到20个，成本更低。
按需拆分：可以按垂直分片（功能模块拆分，如订单库、用户库）或水平分片（同一类数据拆分，如订单按年份分)。

增强可用性

故障隔离：
一个分片挂了，其他分片还能用。比如用户库故障时，商品库仍可正常访问 。

Sharding怎么用？

分片策略选择

• 垂直分片：按业务拆分。例如：用户库、订单库、商品库各自独立。
  适用场景：不同业务模块耦合度低，且单表数据量不大 。
• 水平分片：按数据特征拆分。例如：
  按用户ID分片：用户ID尾号0-9分到10个库。
  按时间分片：2023年订单存库A，2024年存库B。

技术工具实现

• 手动分片：代码中直接指定数据存到哪个库/表，适合简单场景，但维护成本高。
• 中间件分片：用Sharding-JDBC等工具自动路由。例如：
  配置分片规则：指定按“用户ID%10”分到10个库。
  代码零侵入：业务层无需修改SQL，中间件自动改写SQL并分发。
  示例（Sharding-JDBC配置）：

sharding:  
  tables:  
    user:  
      actual-data-nodes: ds${0..9}.user_${0..9}  # 分10个库，每库10张表  
      table-strategy:  
        inline:  
          sharding-column: user_id  
          algorithm-expression: user_${user_id % 10}  # 按用户ID取模分表  

3. 注意事项
   **分片键选择：**选高频查询字段（如用户ID），避免跨分片查询。
   数据一致性：跨分片事务需业务层处理（如最终一致性）。
   **监控工具：**用Prometheus等监控各分片负载，及时调整策略 。

分片 vs 分区 vs 分表

分片（Sharding）：数据分散到多个数据库，适合超大规模数据和高并发。
分区（Partition）：同一数据库内按规则分区块存储，如按时间分区，适合单表数据量大但无需跨服务器 。
分表：同一库中拆成多张表，如订单表拆为order_2023、order_2024，适合中等规模数据。

总结
Sharding是数据库的“拆分大师”，专治数据量大、性能差、扩展难。
用起来三步：选策略→配工具→避坑（一致性、分片键）。
适用场景：电商、社交、物联网等数据量暴增的系统，但需权衡复杂度。