目录一、核心定位二、异同对比相同点三、关键细节差异四、如何选型✅ 选 Sharding‑JDBC满足下面多数条件✅ 选 Sharding‑Proxy满足下面多数条件✅ 混合模式JDBC Proxy 同时使用五、生产落地建议六、常见踩坑提醒Apache ShardingSphere 的两个核心产品Sharding‑JDBC客户端、Sharding‑Proxy服务端另外还有 Sharding‑Sphere‑UI 做管控面板。一、核心定位Sharding‑JDBC客户端分片中间件Jar 包嵌入业务应用无独立服务进程。Sharding‑Proxy数据库代理服务独立进程伪装成数据库服务器应用像访问普通 MySQL 一样连接 Proxy。二、异同对比对比项Sharding‑JDBCSharding‑Proxy部署形态Jar 包和业务应用同进程独立服务进程单独部署接入方式引入 Maven/Gradle 依赖代码 / 配置改造直接连接 Proxy 的 IP 端口几乎不用改业务代码数据库协议复用应用端 JDBC 驱动实现 MySQL 协议客户端可用 JDBC、Navicat、DBeaver 直接连接性能开销几乎无额外网络转发开销性能高多一层代理转发有少量网络、CPU 开销语言限制仅 Java 应用可用不限语言Java、Go、Python、PHP 都可以接入运维管控每个业务应用各自配置分片规则多服务需要同步规则统一一处配置分片规则所有应用共用一套规则连接消耗业务应用直接连接真实数据库连接池在业务侧Proxy 维护后端数据库连接池所有业务连接复用 Proxy 的连接资源适合场景Java 微服务追求高性能多语言系统、DBA 统一管控、异构语言、大量应用共用分片规则缺点非 Java 无法用多服务要同步分片配置每个服务持有后端 DB 连接多一层网络损耗需要运维部署、扩容代理集群有单点风险需要集群化相同点内核完全同一套分片、读写分离、脱敏、分布式事务、广播表、绑定表、加密等功能能力完全一致。都支持 YAML / SpringBoot 配置支持分布式事务XA、Seata、本地事务。都不修改数据库属于中间件对数据库无侵入。⚠️ 新版本 ShardingSphere‑JDBC 5.x 不再支持独立配置文件SpringBoot 项目主要用 yamlSharding‑Proxy 使用conf/server.yamlconf/config‑xxx.yaml。三、关键细节差异连接池Sharding‑JDBC业务应用直接持有后端数据库连接池如果很多微服务实例会导致后端数据库连接数暴涨。例10 个微服务实例每个实例开 50 连接数据库就要扛 500 连接。Sharding‑Proxy所有业务连接打到 ProxyProxy 统一维护到真实 DB 的连接池收敛数据库连接保护数据库。规则维护成本JDBCN 个微服务就要 N 份分片配置修改分片规则需要所有微服务重新发布很容易配置不一致。Proxy只改 Proxy 配置重启 / 热更新 Proxy 即可业务完全不用发布DBA 可以统一管控分片。性能JDBC无中转性能最优延迟几乎等于直连数据库。Proxy多一层网络转发增加 RT一般增加几 ms绝大多数业务可以接受高 QPS 场景要做 Proxy 集群。运维工具Proxy 可以直接用 Navicat 等数据库工具连接DBA 可以直接执行分片 SQL 排查问题JDBC 只能在应用内部日志排查DBA 无法直接连接分片中间件。四、如何选型✅ 选 Sharding‑JDBC满足下面多数条件全部后端服务都是 JavaSpringBoot 微服务追求最低延迟、高性能不想多维护一套中间件服务微服务之间分片规则不一样每个服务独立分库分表业务实例数量不多不会造成数据库连接打满风险点如果实例非常多注意控制各个服务连接池大小防止后端 DB 连接耗尽。✅ 选 Sharding‑Proxy满足下面多数条件存在非 Java 服务Go、PHP、Python 等需要分库分表多个业务服务共用同一套分片库希望分片规则统一维护改规则不需要业务发布DBA 需要直接操作分片集群需要数据库客户端直连分片中间件微服务实例数量非常多需要收敛后端数据库连接数保护数据库希望中间件和业务解耦分片逻辑从业务代码剥离出去风险点Proxy 要做高可用至少部署 2 实例前面加 Nginx/Keepalived 做负载均衡避免单点故障关注代理层 CPU、网络。✅ 混合模式JDBC Proxy 同时使用部分业务 Java 用 JDBC非 Java、DBA 操作使用 Proxy 访问同一套分片集群。注意两套要保持分片规则完全一致否则 SQL 路由错乱。五、生产落地建议SpringCloud 微服务全 Java 栈优先Sharding‑JDBC简单少运维负担如果实例数巨大评估数据库连接数可迁移 Proxy。多语言、中台统一分片、DBA 运维优先Sharding‑Proxy部署集群保证高可用。不要盲目上 Proxy它会增加运维复杂度能 JDBC 搞定就 JDBC。5.x 版本两者内核一致功能没有强弱之分差异只在部署模型。六、常见踩坑提醒Sharding‑JDBC 多实例场景监控数据库连接数每个服务不要配置过大连接池。Sharding‑Proxy 一定要做集群不能单实例跑生产Proxy 本身无状态可以水平扩容。混合使用时JDBC 与 Proxy 的分片算法、分片键配置必须 100% 一致否则路由出错。Proxy 的客户端连接池和后端真实数据库连接池分开调参很多人踩坑。