获课：xingkeit.top/16994/

手把手搭建分片架构，ShardingJDBC 快速上手——数据库水平扩展的第一课

每一个后端系统，都会在某个时刻遇到同一个问题：数据库跑不动了。用户量在涨，订单量在涨，日志量在涨，但数据库的磁盘容量有上限，CPU处理能力有上限，单表几千万行之后，即使加了索引，查询也开始变慢。这个时候，解决方案只有一个——分片。把一张大表拆成多张小表，分散到不同的数据库或不同的服务器上。

分片架构听起来很高深，但在Java生态里，有一个工具让这件事变得出乎意料地简单——ShardingJDBC。它不是一个独立的中间件，而是一个轻量级的Java框架，以jar包的形式嵌入你的应用中，几乎不需要修改业务代码，就能让你的系统拥有分库分表的能力。对于正在从单库单表走向分布式架构的团队来说，ShardingJDBC是快速上手的首选。

从痛点出发：为什么要分片？

在深入ShardingJDBC之前，先理解分片要解决的问题。绝大多数系统起步时都是一张表存所有数据，简单直接。但随着数据量增长，单表会遇到两个瓶颈。

第一个是容量瓶颈。MySQL的InnoDB引擎，B+树索引的层数随着数据量增长而增加。当单表数据量超过2000万行时，B+树高度从3层变成4层，这意味着每次查询需要多一次磁盘IO，性能出现拐点。第二个是写入瓶颈。单数据库实例的写入TPS有物理上限，即使使用SSD，单库的写入能力也很难突破几万TPS。

分片的思路是分而治之。以订单表为例，你可以按照订单ID的哈希值，把订单数据分散到4张结构完全相同的表中，每张表只存四分之一的订单。查询一条订单时，ShardingJDBC根据订单ID计算出应该去哪张表找，然后路由过去。从业务代码的角度看，你依然在操作一张叫做“订单表”的逻辑表，分片的复杂性被框架完全隐藏了。

ShardingJDBC的设计：你写你的SQL，它做它的路由

ShardingJDBC最聪明的地方在于，它对业务代码几乎是无侵入的。你的DAO层依然使用MyBatis或JPA，你写的SQL依然像操作单表一样。ShardingJDBC在数据库连接池和真正的数据库之间插入了一层，它会解析你写的SQL，识别出操作的是哪张逻辑表，根据配置的分片算法计算出实际要操作的真实表，然后改写SQL，再去执行。

这个过程涉及几个关键概念。逻辑表是你在代码中使用的表名，比如order。真实表是数据库中实际存在的表，比如order_0、order_1、order_2、order_3。分片键是用于分片的字段，比如order_id。分片算法定义了分片键的值如何映射到真实表，比如order_id对4取模。分片策略是分片键和分片算法的组合。

理解了这些概念，分片架构的轮廓就清晰了。你只需要在配置文件中声明逻辑表和真实表的对应关系、指定分片键和分片算法，剩下的全部交给ShardingJDBC。

一个完整的分片架构搭建步骤

搭建一个分片架构，通常只需要五步。

第一步是设计分片方案。这是最重要也最容易被忽视的一步。你需要回答几个问题：按哪个字段分片？订单表按订单ID分片最自然，但如果你经常按用户ID查询，可能需要考虑双分片键或者建立冗余表。分多少个库多少张表？建议从小规模开始，比如2个库，每个库4张表，总共8张表。未来需要扩容时，ShardingJDBC支持在线扩容，但复杂度较高，所以初始设计时适当留出余量。是否需要分库？如果写入压力不大只是存储空间不够，可以只分表不分库；如果写入压力也大，就需要分库，同时把表也分掉，形成库表双分片。

第二步是引入依赖。在Spring Boot项目中加入ShardingJDBC的starter，同时确保已经配置了合适的数据源连接池。这一步只是技术操作，没有决策点。

第三步是编写分片配置文件。核心内容包括：真实数据源的名称和连接信息、逻辑表到真实表的映射关系、分片键和分片算法表达式。配置写完后，启动应用，ShardingJDBC会自动创建数据源并替换掉原有的单数据源。

第四步是测试和验证。写入几十条测试数据，观察它们是否按照预期分布到不同的真实表中。然后执行几种常见类型的查询：等值查询、范围查询、IN查询、排序、聚合函数。注意，不是所有SQL都能完美支持，比如跨多个表的JOIN、非分片键上的范围查询，可能性能较差或者结果不准确。及早发现这些边界情况，比上线后再踩坑要好得多。

第五步是调整业务代码。分片架构引入后，业务代码可能需要做一些配合。例如，插入数据时必须确保分片键有值，否则ShardingJDBC不知道把数据放到哪里。再如，批量操作时尽量让同一分片的数据凑在一起，减少跨分片通信。

生产环境必须面对的课题

分片架构在测试环境跑通只是起点，真正的挑战在上线之后。

分布式主键是一个绕不开的坎。单表时可以用数据库自增ID，分表之后每个表独自自增，不同表之间会出现ID重复。ShardingJDBC内置了雪花算法生成器，能生成全局唯一的分布式ID，需要在插入数据时调用。

跨分片查询的性能需要持续关注。当查询条件不包含分片键时，ShardingJDBC不知道去哪个分片找，只能向所有分片广播查询，然后聚合结果。这种全分片扫描随着分片数量增加而线性变慢，应尽量避免。常用的手段是为需要查询的字段建立冗余映射表，或者使用ES等搜索引擎承担复杂查询。

事务一致性要求不同的处理方式。ShardingJDBC支持跨分片的分布式事务，基于两阶段提交协议，但性能损耗较大。实际生产中，大多数业务可以通过设计避免跨分片事务，比如把一个业务流程中涉及的所有数据放到同一个分片上。

从快速上手到游刃有余

ShardingJDBC的价值在于，它让分片架构从一件复杂的事情变成了一个可配置的过程。你不需要理解分布式数据库的内部实现，不需要掌握MySQL的各种分区技巧，只要按照框架的规范设计分片方案、写好配置，就能在几天内把一个单库单表系统改造成支持水平扩展的分片架构。

对于开发者个人来说，掌握ShardingJDBC意味着履历上多了一项硬核技能。数据库分片是高并发系统的必修课，而ShardingJDBC是进入这门课最平滑的入口。当你能够熟练地为一套线上系统设计分片方案、平稳地完成扩容、优雅地应对跨分片查询的挑战时，你在架构层面的能力已经超越了很多同行。

手把手搭建一遍，跑通第一个分片案例，把那些报错信息都见过一遍——这个过程本身，就是最好的学习。ShardingJDBC的文档和社区都非常完善，遇到问题时搜索引擎里大概率已经有答案。剩下的，就是动手。