当单库单表的数据量或写入压力超出 MySQL 实例的能力上限时，业务就必须面对分库分表。直接在应用代码里写分片逻辑会带来极大的维护负担：路由逻辑散落各处、跨库查询难以实现、扩容时数据迁移无处下手。分库分表中间件的作用，就是将分片逻辑从业务代码中剥离，让应用依然像操作一个完整数据库一样，而中间件在底层自动完成 SQL 解析、路由、改写和结果归并。
目前 Java 生态中最为成熟的两个中间件是 Apache ShardingSphere 和 MyCat。它们的设计理念和架构差异较大，但都能有效解决分片场景下的通用问题。
20.4.1 Apache ShardingSphere：多接入模式的生态级方案
ShardingSphere 是一个定位更高的数据库中间件生态，它并不仅限于分库分表，而是围绕分布式数据库场景提供“连接、增量、可插拔”的整套解决方案。其核心产品有两种接入形态：ShardingSphere-JDBC 和 ShardingSphere-Proxy，两种方式共享同一套内核逻辑，即分片、读写分离、数据加密、影子库压测等功能模块。
ShardingSphere-JDBC：以 Jar 包形式直接运行在应用内
- 架构原理：本质上是一个增强版的 JDBC 驱动。应用引入 ShardingSphere-JDBC 的依赖并配置好分片规则后，所有数据库操作仍使用标准的 JDBC 接口，ShardingSphere-JDBC 层会拦截 SQL 语句，进行解析、路由、改写、执行和结果合并，然后通过配置的真实数据源执行。
- 工作流程：SQL → SQL 解析（AST 语法树）→ 根据分片键和分片算法生成路由路径 → 必要时改写 SQL（如将逻辑表名替换为物理分表名、为分页查询修正 limit 偏移）→ 并发执行 SQL 并归并结果（如将各分片的数据在内存中进行排序、分组、聚合）→ 返回统一结果给应用。
- 核心优势：零网络开销，所有处理都在应用进程内完成，性能极高；对 ORM 框架透明，Hibernate、MyBatis 直连即可；无需额外部署中间件节点，运维成本低。
- 适用场景：Java 技术栈为主的后端系统，对性能要求较高，能接受以 jar 依赖方式引入分片能力的环境。
ShardingSphere-Proxy：作为独立的数据库代理部署
- 架构原理：独立进程，模拟 MySQL 协议，应用可以将它当作一个真正的 MySQL 数据库来连接。Proxy 内部集成 ShardingSphere 内核，对外暴露统一的入口端口（默认 3307），接到 SQL 请求后完成解析、路由、改写，然后向真实后端数据库发送 SQL，最后合并结果返回。
- 透明接入：对应用来看，就像连接了一个单机 MySQL，数据分片对应用端完全无感知。可以使用任何编程语言，只需要连接 Proxy 即可。
- 运维代价：需要单独部署和保障 Proxy 实例的高可用，通常需要引入负载均衡（如 ProxySQL、HAProxy）。由于多了一层网络转发，响应时间会比 ShardingSphere-JDBC 略高。
- 适用场景：非 Java 技术栈、老系统改造无法引入 Jar 包、或者希望将分片逻辑集中托管以减少应用侧配置变动的团队。
核心功能原理概述
无论是 JDBC 还是 Proxy 模式，其分片内核都遵循以下关键环节：
- 分片键与算法：支持按单列或多列作为分片键，提供内置算法（取模、范围、哈希、时间等），也可实现自定义算法。
- SQL 解析：ShardingSphere 使用自研的 SQL 解析引擎，支持 MySQL、PostgreSQL、Oracle 等方言，能够识别 DML、DDL、TCL 语句，并判断是否需要分片。
- 分布式主键：内置雪花算法（Snowflake），可生成全局唯一的分布式 ID，解决分片后自增主键冲突的问题。
- 分布式事务：集成 Seata 实现分布式事务能力，对 ShardingSphere 本身来说就是通过 SPI 扩展接入。
- 治理与配置中心：支持通过注册中心（ZooKeeper/Nacos）集中管理分片规则、数据源配置，实现配置动态变更和实例状态管控。
20.4.2 MyCat：以 MySQL 协议代理为核心的经典方案
MyCat 是国内容易上手、使用广泛的开源数据库中间件。它的定位就是数据库代理，所有客户端连接都会连接到 MyCat 服务器，MyCat 再将请求转发到真实数据库。
整体架构
- 协议解析层：MyCat 启动后监听一个服务端口（默认 8066），应用使用 MySQL 原生的 JDBC 或客户端可以直接连接。MyCat 的前端线程会接收 MySQL 协议包，解析出具体的 SQL 命令。
- SQL 解析与路由层：对 SQL 进行词法、语法分析，识别出分片键的值，然后根据预先配置的分片规则（schema.xml 和 rule.xml）计算出目标数据节点（DataNode）。
- 后端数据源管理：每个 DataNode 对应一个真实的 MySQL 数据库（可以是一主多从），MyCat 维护与后端数据库的连接池，对查询请求可以基于负载均衡策略分发到多个从库。
- 结果归并：如果是跨分片查询，MyCat 会将各节点返回的结果在内存中组合、排序或去重，最终返回给客户端。
- 全局序列号：提供本地文件、数据库、时间戳等多种全局 ID 生成方式，保证分片表中的主键唯一性。
MyCat 的使用特点
- 配置驱动：通过 XML 文件定义逻辑库、数据节点、分片规则等，重启后生效。目前也支持注解方式和中文 SQL 智能路由，但生产环境仍建议使用 XML 规则。
- 非侵入式：应用无需任何代码改动，只需将数据库连接地址改为 MyCat 即可，完全透明。
- 功能聚焦：MyCat 的核心价值就是解决分布式存储和查询，其他如分布式事务、数据脱敏等功能相对较弱或需要额外整合。
- 社区版本分化：MyCat 目前存在多个衍生的分支（如 MyCat2、MyCat Server 等），选择时需要注意版本与社区的活跃程度。
20.4.3 选型对比与真实建议
两种中间件技术方案没有绝对优劣，只有是否贴合团队实际的考量：
| 维度 | ShardingSphere-JDBC | ShardingSphere-Proxy / MyCat |
| ----------- | -------------------------------------- | --------------------------------------- |
| 性能 | 极高，无网络转发，无需部署独立进程 | 多一次网络跳跃，略逊于 JDBC 模式 |
| 侵入性 | 需要引入 Jar 包，重新配置数据源 | 应用零侵入，只改连接地址 |
| 语言限制 | 仅 Java（或 JVM 系语言） | 任何语言均可连接 |
| 运维复杂度 | 无额外部署，但配置散落在各应用 | 需要维护中间件高可用，配置集中管理 |
| 功能丰富度 | 分片、读写分离、脱敏、强一致事务等 | MyCat 以分片和读写分离为主，功能较集中 |
| 分布式事务 | 可通过 Seata 集成 | 需自行整合，MyCat 本身支持较弱 |
| 社区活跃度 | Apache 基金会开源，社区活跃，迭代频繁 | 社区相对分散，版本更新较慢 |
真实使用建议：
- 如果你的系统是纯 Java 技术栈，且团队有能力维护配置文件，ShardingSphere-JDBC 几乎是首选。它带来的性能损耗最小，且功能扩展性最强。
- 如果系统含多种语言，或者已有的老项目极其庞大不适合改代码编译，可以使用 ShardingSphere-Proxy 或 MyCat。ShardingSphere-Proxy 的内核与 JDBC 一致，保证功能同步；MyCat 则在纯代理场景下更轻量，但需要注意分支版本的稳定性。
- 无论哪种方案，分库分表都必须谨慎。引入中间件会为后续的 SQL 兼容性带来挑战（如跨库 JOIN、子查询、分页排序等），需要充分测试和制定开发规范。中间件能解决路由问题，但不能完全消除分布式系统的内在复杂性。
- 在云原生环境下，也可以直接考虑基于中间件的 DBaaS 服务（如部分云厂商提供的数据库分片服务），但自建中间件仍然是目前大中型公司的主流选择，因为可控性和灵活度更高。
分库分表中间件是分布式数据库架构演进过程中的核心支柱，理解它的原理和选型策略，有助于你在系统面临数据爆发时做出正确的技术决策，而不是事到临头才仓促拼凑一个读写分离加代码分片的临时方案。