3、分库分表中间件：ShardingSphere-JDBC 核心概念、ShardingSphere-Proxy 架构、MyCat 与 ShardingSphere 对比、主流中间件选型建议
好，咱们进入第三个章节。说实话，分库分表这个事儿，光有理论不行，你得有趁手的工具。今天我就把市面上最主流的几个中间件掰开揉碎了讲给你听。
3.1 ShardingSphere-JDBC 核心概念
先说说 ShardingSphere-JDBC。我个人习惯把它理解成一个「增强版的 JDBC 驱动」。它不部署独立服务，而是直接嵌入到你的应用里。
核心概念其实就三个：数据源、分片规则、执行引擎。
- 数据源：就是你要连接的多个数据库实例。比如你有 4 个库，每个库 4 张表，那就配置 4 个数据源。
- 分片规则：这是灵魂。你要告诉它「按什么字段分」、「分到哪个库」、「分到哪张表」。我见过不少新手把规则写反了，结果数据全跑到了一个库里。
- 执行引擎：它负责把 SQL 解析、改写、路由、归并。说白了，你写一条 SQL，它帮你拆成多条，分别去不同库表执行，最后把结果拼回来。
举个例子：假设订单表按 user_id 取模分库，按 order_id 取模分表。你查某个用户的订单，ShardingSphere-JDBC 会自动算出该去哪个库、哪张表查，你完全不用操心。
💡 我在项目中遇到过一个问题：分片键没选好，导致跨库查询特别多。后来我强制要求所有业务查询必须带上分片键，性能直接翻倍。
3.2 ShardingSphere-Proxy 架构
ShardingSphere-Proxy 跟 JDBC 版本不一样。它是个独立的服务进程，部署在应用和数据库之间。你想想看，它就像一个透明的代理层。
它的架构是这样的：
- 协议层：兼容 MySQL、PostgreSQL 协议。你的应用连它就像连一个普通数据库。
- 核心层：负责 SQL 解析、路由、改写、执行、归并。跟 JDBC 版本用的是同一套内核。
- 存储层：连接后端的真实数据库集群。
为什么要用 Proxy 模式？我总结了两点：
- 对应用无侵入：你不需要改代码，只需要改数据库连接地址。
- 适合异构系统：比如你的团队有 Java、Go、Python 多个语言，用 Proxy 统一接入最省事。
⚠️ 注意：Proxy 模式会多一层网络开销。我曾经压测过，性能损耗大约在 5%-10% 之间。如果你的业务对延迟极其敏感，建议优先考虑 JDBC 模式。
3.3 MyCat 与 ShardingSphere 对比
很多老项目还在用 MyCat。说实话，MyCat 当年确实解决了分库分表的问题，但现在已经有些跟不上时代了。
我直接给你列个对比表，一目了然：
| 对比维度 | MyCat | ShardingSphere |
|---|---|---|
| 架构模式 | 仅 Proxy 模式 | JDBC + Proxy 双模式 |
| SQL 支持 | 有限，复杂 SQL 容易报错 | 支持大部分 SQL，包括子查询、JOIN |
| 分布式事务 | 弱支持 | 支持 XA、Seata、柔性事务 |
| 社区活跃度 | 较低，更新缓慢 | Apache 顶级项目，迭代快 |
| 配置方式 | XML 配置，较繁琐 | YAML/Spring Boot 配置，更灵活 |
| 性能 | Proxy 模式，有网络开销 | JDBC 模式无额外开销，Proxy 模式略优 |
我的建议：如果你还在用 MyCat，并且项目不复杂，可以继续用。但如果是新项目，我强烈建议直接上 ShardingSphere。为什么？因为 MyCat 的 SQL 解析能力太弱了，我曾经被它坑过一次——一条带子查询的 SQL，在 MyCat 里跑直接报错，换成 ShardingSphere 就没事。
3.4 主流中间件选型建议
好，到了大家最关心的环节：到底选哪个？
我根据不同的场景，给你几个选型建议：
- 场景一：Java 单体应用，对性能要求极高
→ 选 ShardingSphere-JDBC。嵌入应用，零网络开销，性能最好。 - 场景二：多语言团队，不想改代码
→ 选 ShardingSphere-Proxy。统一接入，对应用透明。 - 场景三：老项目迁移，已经在用 MyCat
→ 如果业务简单，可以继续用 MyCat。但建议逐步迁移到 ShardingSphere。 - 场景四：需要分布式事务支持
→ 选 ShardingSphere。它内置了 XA 和 Seata 支持，MyCat 在这方面比较弱。 - 场景五：数据量不大，只是简单分表
→ 其实可以考虑直接用数据库自带的方案，比如 MySQL 的分区表。别一上来就上中间件，过度设计也是坑。
💡 我个人习惯：新项目一律用 ShardingSphere-JDBC。除非团队里有非 Java 成员，才会考虑 Proxy 模式。记住一个原则——能少一层就少一层，性能是第一位的。
嗯，这一章的内容就到这里。说白了，选中间件没有银弹，关键看你的业务场景。下一章我会带你手把手配置 ShardingSphere-JDBC，到时候咱们实战见。