几乎所有项目都会经历这样一个过程业务初期数据量小单表百万级数据普通索引、基础SQL完全能稳稳支撑业务但随着用户体量、订单流水、日志数据持续暴涨单表数据突破千万、直奔上亿时所有隐藏问题会集中爆发接口响应变慢、高峰期数据库卡顿、查询超时、写入延迟升高。我们也完整走完了这一整套曲折的优化之路从最基础的调参改SQL到早期中间件选型踩坑再到最终落地成熟稳定的分布式数据库架构每一步都是线上真实故障打磨出来的经验。最开始我们坚信优化能解决一切问题反复调整MySQL全局配置、逐行优化慢SQL、批量梳理新增索引、清理冗余字段。但很快发现所有优化都只是「续命手段」无法根治上亿级数据的底层瓶颈。一个系统四百多张表随便划拉几张基本上都是上千万上亿的数据量单纯的优化已经解决不了问题。然后我们开始研究分库分表中间件早期因ShardingSphere生态不成熟首选行业主流的Mycat搭建架构但随着业务迭代、技术栈升级Mycat的兼容性、性能瓶颈、SQL 支持受限、更重要的一点运维配置极其复杂、稳定性短板彻底暴露最终我们完成全量迁移落地ShardingSphere JDBC Proxy 双架构同时搭配主从读写分离形成适配高并发、亿级数据的最终稳定方案。一路走来很多核心疑问困扰了我们很久✅ JDBC 和 Proxy 两种架构到底该怎么选型各自适配什么业务场景✅ 两种模式配置差异、Spring版本兼容区别在哪里✅ 什么场景只分表、什么场景必须分库对SQL查询有哪些影响✅ 分库分表如何和主从读写分离完美联动实现性能最大化今天结合我们完整踩坑演进史 线上落地 生产选型标准给大家分享一下。一、核心选型ShardingSphere JDBC / Proxy 到底怎么选1、ShardingSphere-JDBC 适配场景核心定位无中间件、零损耗、高性能、Java核心业务专属核心交易、订单、支付、流水等高并发 OLTP 业务全站技术栈为 Java/SpringBoot无多语言异构服务追求极致响应速度无法接受额外网络转发损耗团队运维人手有限不想新增中间件维护成本本质Jar包嵌入业务进程直连分片数据库无中心化节点、无网络转发性能最优。这也是我们部分选择用这种方式的原因由于我们的数据支持第三方回流一直处于高并发的状态。2、ShardingSphere-Proxy 适配场景核心定位统一入口、集中治理、多语言兼容、低侵入改造后台统计、报表、数据导出、大数据量慢查询等 OLAP 业务存在 Go/Python/PHP 等非Java服务访问分片数据老旧系统改造不想改动业务代码仅更换数据库连接地址微服务实例数量多JDBC模式易打爆MySQL连接数需要DBA直接通过Navicat操作分片库、统一管理分片规则本质独立代理服务统一接管所有数据库请求连接集中复用牺牲微量性能换取极强的运维可控性。3、我们最终落地策略核心交易服务 JDBC保障高并发、低延迟、高可用非核心报表/第三方服务 Proxy统一治理、降低运维成本、规避连接爆炸问题二、深度对比JDBC vs Proxy 配置差异、Spring版本兼容区别1、核心配置与架构差异对比项ShardingSphere-JDBCShardingSphere-Proxy部署方式Jar内嵌随SpringBoot项目启动独立进程、独立端口、集群部署配置位置各业务服务yml配置分散管理Proxy统一配置 Nacos动态配置规则更新修改配置需重启业务服务动态刷新业务服务无需重启数据库连接多实例会放大连接数易打满MySQL上限连接集中复用彻底解决连接爆炸性能损耗几乎0损耗多一层网络转发轻微性能损耗代码侵入需引入依赖、配置分片规则零代码侵入仅改连接地址2、Spring/JDK 版本兼容核心区别避坑重点Mycat完全不兼容 SpringBoot3、JDK17新技术栈项目直接阵亡是淘汰核心原因ShardingSphere-JDBC 5.3全版本兼容支持 SpringBoot2.x/3.x、JDK8~JDK21适配虚拟线程新项目ShardingSphere-Proxy无Spring、JDK依赖完全独立运行新旧业务、不同技术栈可统一接入改造兼容性拉满三、生产核心规范分表、分库适用场景 SQL查询影响很多项目架构臃肿、SQL难写、分布式事务泛滥核心原因是不分场景乱分库、乱分表。我们经过多次踩坑总结出严格的生产落地标准。当然更多的还是要根据具体的业务来分析。1、只分表、不分库90%亿级数据场景首选适用条件单表数据破千万/上亿单库 CPU、内存、IO 压力正常无硬件瓶颈业务QPS高、数据量大但单机数据库可承载无大量跨库联表、跨库事务需求典型业务订单表、支付流水表、操作日志表、用户行为记录表SQL查询影响同库分片联表查询、分页排序兼容性极好无跨库网络开销查询性能稳定高效几乎规避分布式事务业务复杂度极低2、必须分库仅极端瓶颈场景适用条件全部满足才执行单库硬件常年打满CPU持续高负载、IO打满、连接数爆满数据量、QPS双高单库物理性能达到上限单表分片优化后依旧无法缓解数据库压力SQL查询影响高危避坑严格禁止随意跨库JOIN极易引发性能雪崩跨库分页、排序、聚合查询成本大幅提升必须依赖分布式事务架构复杂度、运维成本翻倍生产铁律能分表不分库、能不分就不拆分。分表是优化手段分库是最终兜底方案。四、架构联动ShardingSphere 主从读写分离方案分片解决单表数据量大的存储瓶颈读写分离解决查询QPS过高的并发瓶颈二者必须联动使用才能实现架构最优解。1、整体架构链路主库全权承载新增、更新、删除、事务写操作保证数据一致性从库集群承载所有列表查询、分页、统计、导出、慢查询分流主库压力ShardingSphere统一接管自动完成分片路由 读写分离路由业务无感知2、双架构分工策略JDBC核心服务读写分离分片双重路由保障核心交易读写均衡、低延迟Proxy报表服务所有OLAP慢查询、大数据量统计全部引流至从库彻底隔离读写压力不影响核心交易3、核心避坑要点读写分离无法解决单表数据量大的问题只能扛并发必须配合分片/归档使用分片无法解决查询并发压力必须靠读写分离分流QPS最终治理链路基础优化 → 冷热数据归档 → 单表分片 → 读写分离 → 极端场景分库五、以下部分配置DemoJDBC Proxy 完整配置1、SpringBoot3 ShardingSphere-JDBC 完整配置分表读写分离核心依赖 pom.xmlsharding-config.yaml文件配置部分截图当然也可以直接在application.yaml配置application.yml 完整可上线配置spring: shardingsphere: # 多数据源配置主库从库 datasource: names: master,slave1 master: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/db_master username: root password: xxx slave1: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://127.0.0.1:3306/db_slave username: root password: xxx # 读写分离规则 rules: readwrite-splitting: >2、ShardingSphere-Proxy 完整可上线配置Proxy 无需改动业务代码仅需配置服务端规则业务侧修改连接地址即可适配所有技术栈。server.yaml全局配置mode: type: Cluster repository: type: Nacos props: nacos-server-addr: 127.0.0.1:8848 nacos-namespace: public nacos-group: DEFAULT_GROUP # 认证配置 authentication: users: root: password: xxx sharding: password: xxx # 全局属性 props: sql-show: true sql-simple: true max-connections-size-per-query: 10config-sharding.yaml分片读写分离核心规则databaseName: sharding_db # 数据源配置 dataSources: master: url: jdbc:mysql://127.0.0.1:3306/db_master?useSSLfalseserverTimezoneAsia/Shanghai username: root password: xxx connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 600000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 20 slave1: url: jdbc:mysql://127.0.0.1:3306/db_slave?useSSLfalseserverTimezoneAsia/Shanghai username: root password: xxx connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 600000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 20 # 读写分离规则 rules: - !READWRITE_SPLITTING dataSources: ds: writeDataSourceName: master readDataSourceNames: - slave1 loadBalancerName: round_robin # 分表规则 - !SHARDING tables: order_info: actualDataNodes: ds.order_info_${0..3} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: user_id_mod_4 shardingAlgorithms: user_id_mod_4: type: MOD props: sharding-count: 4业务侧接入方式业务项目直接连接 Proxy 地址无需任何分片、读写分离配置和正常连接MYSQL数据库一样spring: datasource: url: jdbc:mysql://127.0.0.1:3307/sharding_db username: sharding password: xxx六、最终架构总结1、基础优化的局限性SQL、索引、数据库参数优化仅能短期续命无法根治上亿级数据的底层性能瓶颈。2、Mycat淘汰核心原因生态停滞、新版技术栈不兼容、SQL兼容性差、运维黑盒完全不适配现代SpringBoot3、JDK17项目。3、双架构落地价值JDBC保核心业务性能Proxy保非核心业务运维取长补短兼顾性能与可维护性。4、分层治理核心逻辑先优化归档、再分片、最后读写分离非极端硬件瓶颈绝不轻易分库避免过度设计。JDBC 做业务读写Proxy 提供 DBA 查询、报表、数据分析入口使用同一个配置中心 (Nacos) 统一管理分片规则两套接入端共用一套分片逻辑深耕后端生产实战分享真实线上踩坑、架构演进、MySQL亿级治理、SpringBoot3新版本实战关注我持续输出落地干货欢迎点赞收藏关注持续更新线上踩坑实录。