企业官网建设流程全解析

ShardingSphere用了快四年，团队的订单库从单库单表一路拆到16库32表，JDBC和Proxy两种模式都深度踩过坑。这篇文章不打算重复官方文档，而是想把我自己总结的选型思路、分片边界判断方法，以及读写分离和分库分表联动配置的完整实践过程梳理一遍，给正在纠结这些问题的朋友一个可以直接参考的答案。

1. 先搞懂JDBC和Proxy到底差在哪

1.1 两种模式的核心差异

很多人第一次接触ShardingSphere时，最困惑的就是JDBC和Proxy两种模式到底怎么选。其实这两种模式一个本质是"应用内嵌"，一个是"独立服务"，理解这一点就抓住了核心。

JDBC模式说白了就是一个增强版的数据库驱动。你的业务应用还是走JDBC接口连数据库，只是这个驱动内部帮你做了SQL解析、路由、改写、归并等一系列操作。它是以jar包的形式跑在你的应用进程里的，应用连的还是原来的数据库地址。相当于给你配了一个贴身翻译，在你的进程内部帮你把对"逻辑表"的访问翻译成对"真实表"的访问。

Proxy模式则完全不同。它是一个独立部署的中间件服务，对外暴露一个MySQL/PostgreSQL协议端口。你的应用连接的不再是真实的MySQL，而是这个Proxy服务。Proxy帮你做了协议解析，再以MySQL客户端的身份去连接后面的真实数据库集群。这相当于给整个数据库层加了一个"前置网关"，所有客户端都统一从这个网关进出。

这两种架构差异直接决定了它们后续所有的选型取舍：

• 部署方式：JDBC模式和应用同进程，随应用一起启动；Proxy模式是独立服务，需要单独维护。
• 支持的客户端语言：JDBC模式只支持Java（虽然也有Go版，但生态远不如Java成熟）；Proxy模式对所有支持MySQL/PostgreSQL协议的语言都开放，理论上Python、Node.js、Go、C++都能连。
• 数据聚合能力：JDBC模式在每个应用进程里做聚合，适合数据量可控的场景；Proxy模式在服务端统一聚合，适合数据量大的场景，且聚合逻辑只维护一份。

1.2 一张表看清选型边界

我把四年实战下来的判断标准整理成了一张表，按这个逻辑去选基本不会出大问题。

1.3 我建议的选型原则

选型这件事没有绝对的"哪个更好"，只有"哪个更适合你当前的处境"。我自己的经验是三个判断维度：

第一个维度看团队规模。如果你是一个20人以下的后端团队，技术栈以Java为主，数据库实例数量也不多，那JDBC模式几乎是最优解。它开销小、上手快、出了问题好排查，不需要额外养一套中间件的运维能力。我们早期就是这种情况，一个核心交易库拆分直接引入JDBC模式，两周就完成了上线。

第二个维度看数据库的使用方范围。如果你们的数据库只给一个业务系统用，那JDBC模式没有任何问题。但如果DB层是多个团队共享的资源，大家都需要访问同一套分片集群，或者有非Java语言的服务需要接入，那Proxy模式的集中管理优势就很明显了。我见过太多案例，JDBC模式用着用着，业务线多了，各自在配置里写了一套分片规则，改配置需要所有应用一起发布，最后被迫迁移到Proxy。

第三个维度看的性能敏感程度。Proxy模式因为多了一层网络转发，纯查询场景下的性能损耗大概在5%-10%左右，如果SQL特别复杂、返回数据量大，损耗还会进一步放大。而JDBC模式因为路由和归并都在进程内完成，性能几乎无损。如果你对性能有极致要求，且Java技术栈统一，JDBC模式会更稳。

实际中还有一个很关键的判断点：你未来的数据量会涨到多大。如果预计单表很快会突破千万甚至亿级，需要持续扩容，Proxy模式在扩缩容时的优势就会体现出来。ShardingSphere有专门的弹性迁移组件，可以对Proxy底层的真实数据做无损搬迁，应用层面甚至感知不到。JDBC模式做扩容则要复杂得多，需要协调所有应用重新发布。所以如果你已经能看到三五年的增长曲线，建议一开始就上Proxy，不要先JDBC后Proxy来一次痛苦的架构迁移。

2. 分库分表的边界：什么时候该动手

2.1 分片阈值怎么判断

聊到分库分表，最常见的问题就是"数据量到多少才需要分？"这是一个没有标准答案的问题，但我可以给你一个判断框架，而不是一个拍脑袋的数值。

先看容量维度。MySQL单表在数据量和索引大小达到一定规模后，B+树的层级会增加，随机IO的成本会明显上升。以我个人经验，单表行数超过2000万左右，或者单表数据文件超过50GB，就应该认真考虑分片了。当然这个阈值和你的硬件环境、查询模式强相关。SSD环境下，3000万甚至5000万行可能还能扛，但如果你的查询模式有大量的范围扫描、多索引回表，2000万行可能已经非常吃力了。

再看性能维度。判断是否分片的关键指标不是"数据量"，而是"单库单表的QPS是否已经压榨到极限"。你可以通过MySQL的performance_schema或者慢日志去统计，当单表每秒承载的读写次数达到8000-10000次，而CPU和IO已经出现周期性瓶颈时，就是该考虑分片的时候了。

还有一个我比较常用的估算方法：算"热点数据增长率"。假设你的业务每天新增100万条订单数据，一年就是3.6亿条。如果订单只保留最近三个月的活跃数据，单表数据量会稳定在9000万左右；如果历史数据也频繁查询，那这个数字会持续攀升。算出这个数后，心里就要有底了：我的表能撑多久，什么时候到极限。

2.2 分片键选型和分片策略

分片键的选型是整个分库分表设计中最关键、也最不可逆的决策。改分片键相当于把已分布的数据全部重洗一遍，代价极大，所以一开始就要想清楚。

分片键的第一原则是"高频查询必须带它"。如果你的业务是典型的用户维度访问——查我的订单、查我的积分、查我的收藏——那user_id就是不二之选。按user_id做hash取模分片，所有单用户维度的查询都能精确定位到唯一分片，完全不需要全库扫描。

但纯用户维度分片有一个很经典的问题：后台运营需要按时间范围统计订单。这时候如果没有一个时间维度的全局索引，就需要做跨全分片的聚合查询。我有一次就卡在报表需求上，后来加了一张"用户-订单-分片"的映射表来兜底，才把这个问题解决。所以如果你明知道会有后台聚合查询的需求，分片键的设计要留好这种后手计划。

确定好分片键后，就是选分片策略。最常见的三种：

• 哈希取模：按user_id hash后对分片数取模，数据分布均匀，但扩缩容需要重新分布。
• 范围分片：按时间或者ID区间切片，扩容方便，但数据可能倾斜在最新分片上。
• 一致性哈希：分布在环上按虚拟节点路由，扩容影响面小，但实现复杂，且需要自己处理虚拟节点与真实节点的映射。

如果追求简单可靠、业务以点查询为主，哈希取模最稳妥。如果业务有明显的强序需求，比如按时间归档，范围分片更合理。两者也可以结合，比如先范围再hash，但复杂度会高一个量级，新手慎用。

2.3 常见的分片边界误区

分库分表这件事，最怕的不是不分，而是乱分、早分、过度分。

过早分片是我见过最多的一个坑。很多团队刚把单表数据量做到500万，看了几篇分库分表文章，就急吼吼地要拆库拆表。结果业务还在快速迭代，分片规则改一次就疼一次，开发效率被拉低了一大截。我个人的建议是：如果数据量还能扛1-2年的增长，那就先不分。分库分表是给系统续命的架构手段，不是用来炫技的。

另一个误区是过度分片。比如单表才2000万行，非要用64个分片，结果每个分片才30多万行，分布式事务的复杂度、跨分片聚合的开销反而拖垮了性能。分片的粒度应该以"单分片数据量控制在合理范围"为目标，比如每个分片500万-1000万行，这样单个分片既不会太小导致过度拆分的开销，也不会太大导致单片查询压力过大。

最容易被忽略的还有"分库不分表"和"分表不分库"的区别。分库解决的是并发连接数和整体QPS瓶颈，分表解决的是单表数据膨胀和索引效率问题。两者目标不同，实践中经常需要联动处理。当整个数据库的活跃连接数逼近上限、CPU和IO成为瓶颈时，优先分库；当单表数据量持续膨胀、查询越来越慢时，优先分表。

还有一个边界问题是"到底要不要保留全量数据在一个库里做备份"。有些团队为了查询方便，分片之后保留了一张全量汇总表。这个做法意味着所有写入都要双写，事务一致性、存储成本都会翻倍。除非有极强的即时全量查询需求，否则不建议这么干，用离线数仓做全量分析是更合理的方式。

3. 分库分表与读写分离的联动设计

3.1 为什么要把两者联动起来

在很多人的认知里，分库分表和读写分离是两件独立的事。实际上，在生产高并发场景下，这两者几乎总是同时出现的。原因很简单：一旦你的数据量大到需要分片，说明你库的主库写入压力已经不小了；此时再叠加高并发的读流量，主库扛不住，就需要把读压力分流到从库。

但这里有一个容易被忽略的点：读写分离和分库分表联动时，规则配置是有顺序依赖的。你要先决定哪些库参与分片，再在分片的基础上给每个库配置读从库。实际配置时，每一个分片主库都得配置对应的从库集合，否则流量路由过去后，读压力还是会压在主库上。

联动配置的典型架构是：一主多从的集群作为底层存储，每个分片主库负责写入，多个从库分担读流量。通过ShardingSphere，逻辑上你把一个逻辑表映射到多个物理分片，每个分片又对应一组主从数据源。这样一条查询SQL到达ShardingSphere后，先按分片键定位到具体分片，再按读写分离规则将读流量转发到对应的从库。

3.2 读写分离规则的核心配置项

ShardingSphere的读写分离规则，核心配置就是数据源分组：把一个主库和它的一组从库打包成一个"数据源组"，然后指定负载均衡算法。官方的算法有三种常用的：轮询、随机、权重。我实际用的最多的就是轮询和权重。

轮询适合从库配置完全一致的场景，简单公平，每个从库轮着来。随机适合从库连接数不均的场景，但其实效果和轮询差别不大。权重适合从库机器性能有差异的场景，比如一个从库是32核，另一个是16核，那权重就配置成2:1。这里有一个我踩过坑的细节：权重算法是按访问次数来轮询的，不是按实际负载，如果SQL复杂度差异很大，权重效果会失真，需要定期观察从库的实际负载来调整。

除了负载均衡算法，还有一个让我特别推荐的配置是dynamic-strategy的动态读写分离策略。传统的读写分离是静态的，从库挂了之后需要手动摘除。ShardingSphere JDBC 5.1.0以后支持动态读写分离，可以定期探测从库的延迟和可用性，自动摘除延迟过高或不可用的从库节点，数据源的故障转移就稳妥得多。

3.3 主从复制延迟怎么处理

读写分离的最大痛点永远是主从延迟。MySQL默认的异步复制在某些高并发写入下，延迟可能达到几百毫秒甚至几秒。在这个延迟窗口内，你写入一条数据后立刻去读，很可能读不到——因为读请求已经路由到了还没同步完成的从库。

这个问题有几种常见的应对策略：

第一种是强制路由主库。对一致性要求极高的操作，通过Hint注解或者ShardingSphere的hint路由机制，把某条SQL强制发到主库执行。代价是这部分读流量还是会压到主库，所以只适合"刚写完立刻读"这类高频短操作。我通常会在用户下单支付成功的回调逻辑里，强制走主库读取刚写入的订单状态。

第二种是延迟阈值控制。ShardingSphere动态读写分离支持配置延迟阈值，当从库的复制延迟超过设定值（比如10秒），这个从库会临时从读流量中摘除，等延迟恢复后再自动加回来。这是一个兜底方案，保证读流量不会路由到延迟过大的从库上，但瞬间的可用从库数量会减少。

第三种是业务兜底。在代码里对一致性要求高的数据做本地缓存，并设置极短的过期时间（如1-2秒），在这个时间窗口内从缓存读，过期后再去数据库读。这个方案最简单，但对业务有一定的侵入性，而且缓存本身就是一套要维护的系统。

实际上最靠谱的方案是组合拳：核心链路强制主库读，次核心链路接受微秒级延迟，再配合延迟阈值把所有从库的延迟控制在上限内。过分追求所有读都絕對一致是不现实的，关键是识别出哪些读必须强一致，哪些读可以接受暂时滞后。

3.4 分布式事务的取舍

分库之后，原来一个本地事务可能变成跨多个库的事务，这是分库分表后最棘手的问题之一。订单创建时要同时写订单表和账户流水表，如果这两张表被分到了不同的库，原来一个事务就能搞定的事，现在变成了跨库事务。

ShardingSphere提供两种分布式事务方案：XA强一致和Seata最终一致。我个人的选型建议很明确：短事务、对一致性要求极高的，用XA；长事务、涉及外部系统调用的，用Seata。但是——这里我要强调一点——能避免跨库事务就应该尽量避免跨库事务。

避免跨库事务最实用的思路就是"绑定表"和"一致分片"。如果你有两张表总是出现在同一条SQL里做关联查询，或者总是在同一个事务里被一起修改，那它们在分片时就应当使用相同的分片键，保证它们总是落在同一个分片上。ShardingSphere的绑定表功能就是做这个的，配置成绑定表后，关联查询会在各分片内直接完成，不需要跨库合并。这样一来，原来看起来要引入分布式事务的场景，最终可能只需要本地事务就能解决。

4. 实操过程：从零搭建分库分表读写分离环境

4.1 环境准备

我先说明一下本次实操的环境版本：ShardingSphere JDBC 5.3.2、Spring Boot 2.7.x、MySQL 8.0。这套组合是目前生产环境最常见的搭配之一，文档齐全，坑也基本被踩平了。

硬件准备环节，我需要3个MySQL实例：1个主库、2个从库，你也可以用Docker在本地模拟。主库实例命名master，从库命名为slave_a和slave_b，分别模拟不同的机器。三个实例之间配置好主从复制，这一步很简单，在从库上执行CHANGE MASTER TO指向主库的binlog坐标即可，我这里就不展开复制配置的细节了。

准备两个数据库：ds_0和ds_1，分别映射到两台MySQL服务器，模拟分库后的两个物理库。每个库里建两张分表t_order_0和t_order_1，最后构成2库×2表的分片拓扑。建表语句如下：

CREATE TABLE t_order_0 ( order_id BIGINT PRIMARY KEY, user_id BIGINT NOT NULL, order_no VARCHAR(64) NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL, create_time DATETIME NOT NULL, KEY idx_user_id (user_id) ); CREATE TABLE t_order_1 LIKE t_order_0;

4.2 构建数据源拓扑

这一步是整个配置的关键。我们需要配置两组数据源，每组代表一个分片。每个分片组里包含主库和对应的从库。在ShardingSphere的配置体系里，数据源的定义在最外层，分片规则和读写分离规则在rules里。

先在Spring Boot的配置文件里声明数据源：

spring: shardingsphere: datasource: names: ds_0_master, ds_0_slave_a, ds_0_slave_b, ds_1_master, ds_1_slave_a, ds_1_slave_b ds_0_master: type: com.zaxxer.hikari.HikariDataSource driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://192.168.1.10:3306/ds_0 username: root password: root ds_0_slave_a: # 同上，指向192.168.1.11:3306/ds_0 ds_0_slave_b: # 同上，指向192.168.1.12:3306/ds_0 ds_1_master: # 指向192.168.2.10:3306/ds_1 ds_1_slave_a: # 同上，指向192.168.2.11:3306/ds_1 ds_1_slave_b: # 同上，指向192.168.2.12:3306/ds_1

这里要注意一个细节：多个从库如果只配置一个，读写分离的负载均衡就没有意义。生产环境至少配置两个从库，才能体会到负载均衡的效果。

4.3 配置分片规则与读写分离规则

接下来是核心的规则配置。我们需要配置两个规则块：!READWRITE_SPLITTING和!SHARDING。

spring: shardingsphere: rules: readwrite-splitting: >[INFO ] ShardingSphere-SQL: Logic SQL: INSERT INTO t_order (...) VALUES (...) [INFO ] ShardingSphere-SQL: Actual SQL: ds_1 => INSERT INTO t_order_1 (...) VALUES (...)

查询数据时观察日志：

[INFO ] ShardingSphere-SQL: Logic SQL: SELECT * FROM t_order WHERE user_id = ? [INFO ] ShardingSphere-SQL: Actual SQL: ds_0_slave_b => SELECT * FROM t_order_0 WHERE user_id = ?

从日志可以看到：写入路由到了分片主库ds_1，并写入物理表t_order_1；查询路由到了分片从库ds_0_slave_b，从物理表t_order_0读取。这说明分片和读写分离已经正确联动。

为了进一步确认读写分离的负载均衡是否生效，可以用一个简单的统计接口查询多次，观察日志中SQL实际执行节点的分布情况。如果轮询策略生效，两个从库应该交替出现在日志里。

4.5 动态扩容的思路

分片配置好了以后，迟早要面对扩容的问题。以2库2表扩容到4库4表为例，这涉及两类工作：一是数据迁移，把原有各分片的数据按新的分片规则重新分布；二是配置变更，让ShardingSphere的路由规则指向新的拓扑。

ShardingSphere的弹性迁移组件（Scaling）可以在线完成数据搬迁，它会把旧分片的数据按新规则扫描、清洗、写入新分片，数据校验通过后自动切换配置。但我实际用的过程中发现，这个过程的坑主要在数据校验阶段，数据量大了以后校验耗时很长，期间如果有持续写入，增量数据同步也容易出现延迟累积。所以我的建议很简单：扩容这个操作，尽量在业务低峰期做，提前评估好存量数据量和迁移耗时，不要等活动开始了才临时抱佛脚。

配置变更方面，把上面的actual-data-nodes从ds_$->{0..1}.t_order_$->{0..1}改成ds_$->{0..3}.t_order_$->{0..3}，同时数据源部分补上新增的ds_2、ds_3相关配置即可。但注意，分片算法的取模基数也要从2改成4，否则路由就会错乱，这一点极其容易漏。

5. 常见问题与排查技巧实录

5.1 问题速查表

我把实践中最常遇到的问题整理成了一张速查表，方便随时查阅：

5.2 定位问题的方法论

排查ShardingSphere的问题，我总结出了一个固定套路：先看SQL日志，再看配置，最后才看代码。

第一步永远是看SQL日志。ShardingSphere会完整打印逻辑SQL和实际SQL，这是判断路由是否正确的最直接证据。比如你想确认一条查询到底有没有走到从库，日志里的Actual SQL会明确告诉你执行节点。如果这个节点不是你预期的那个，那么十有八九是配置有问题，而不是SQL的问题。

第二步检查配置。ShardingSphere 5.x版本的配置采用YAML格式，一个很常见的坑是缩进不规范导致配置静默失效，日志里完全没有报错，但行为就是不对。还有数据源名称的拼写错误，这种问题最难发现，因为配置加载不会立即报错，只有运行时才暴露。

第三步结合业务场景分析。有些问题排查到最后发现不是配置问题，而是业务SQL本身写得不好。比如SQL里有一个JOIN操作，关联的另一张表没有配置绑定表关系，导致ShardingSphere需要跨分片拉取数据再做内存归并，性能自然就差了。这种问题靠配置无法根治，得从业务SQL入手优化。

5.3 避坑经验与心得分享

建了绑定表关系后，关联查询仍然执行了跨库合并。这个问题的原因是：ShardingSphere只在两张表的关联字段都能路由到相同分片时才走绑定表优化，如果关联字段不是分片键，或者有一张表的分片键不在JOIN条件里，绑定表就不会生效。所以配置绑定表之前，要确认关联查询确实带了分片键条件。

还有一次在配置读写分离时踩了一个很隐蔽的坑：我把写库的数据源名称写成了ds_0_master，从库写成ds_0_slave，但读写分离规则里配置的负载均衡算法名是round_robin_0，而加载器里定义的是roundRobin_0——一个字母大小写不一致。ShardingSphere在加载配置时对这种命名不一致并不报错，但运行时会提示找不到负载均衡算法，然后回退到默认策略，从库流量还是没被分担。这种低级错误排查起来费了不少劲，我后来养成了每次配置完都手动跑几条SQL验证路由节点的习惯。

还有一个值得说的经验是：分库分表不等于性能无限提升。分片后如果业务SQL大量不带分片键，全路由查询依然会拖垮整个集群。我参与过的一个业务系统，原本单表查询很快，分片后反而变慢了。后来排查发现，这个系统的查询模式完全不是用户维度的，大多数查询都是按时间范围做的。对这种业务，正确的分片维度应该是时间，而不是用户ID。从这里我深刻体会到：分片键的选择必须和业务实际的查询模式深度绑定，不能拍脑袋决定。

最后分享一个让我受益很多的小技巧：上线前在测试环境搞一个只读压测脚本，随机生成多种模式的SQL，跑一段时间专门检查ShardingSphere日志里有没有全路由的情况。这个脚本帮我提前发现了很多隐藏的"全路由"SQL，避免了上线后主从被拖垮的事故。