年底好几个项目都在压测订单表数据量冲上两千万之后慢查询肉眼可见地多了起来DBA那边的告警邮件一封接一封。这类场景一旦出现基本就绕不开ShardingSphere这套方案来治理数据分片和读写分离了。但真到选型的时候身边同事第一句基本都是JDBC和Proxy到底选哪个紧接着第二个问题是哪些表该分库、哪些表该分表、边界怎么划再往后就是读写分离和分片能不能一起上、会不会互相打架。这篇文章就围绕这三个问题把我压测和上线过程中的具体判断依据、配置方式、踩坑教训完整梳理一遍。无论你是刚开始调研分库分表还是已经在用ShardingSphere但配置总是不生效这篇都值得对照着实操一遍。1. 先摸清两套形态的底牌JDBC和Proxy到底差在哪ShardingSphere其实是一套双形态的解决方案JDBC形态和Proxy形态底层共享同一套分片内核、同一个路由引擎和改写引擎但部署位置和应用接入方式完全不同。这个差异决定了它们从出生起就面向不同的使用场景不是随便二选一那么简单。1.1 架构形态和接入方式的核心差异ShardingSphere-JDBC是一个JAR包以client模式嵌入到业务应用进程里。应用通过DataSource接口拿到连接这个连接背后是ShardingSphere包装过的逻辑连接真正驱动行为的是它内置的一套分片引擎。它不独立部署不占用额外端口业务代码里的JDBC API调用方式几乎不变把原来的DataSource换成ShardingSphere提供的实现类就能接管路由逻辑。因为所有分片计算、SQL改写都发生在应用本机链路非常短延迟开销通常只有毫秒级甚至更低。ShardingSphere-Proxy则是独立部署的中间件服务启动后对外暴露一个数据库协议端口。业务应用不再直连数据库而是把Proxy当成一个数据库实例来连。它背后可以接MySQL、PostgreSQL等真实数据库。相当于在应用和数据库之间插入了一个数据库网关应用用普通的MySQL客户端或者JDBC驱动连上它剩下的分片逻辑全在Proxy服务端完成。我把两者在工程层面的差异整理成了下面这张对照表平时做技术方案评审时基本可以直接引用对比维度ShardingSphere-JDBCShardingSphere-Proxy部署形态嵌入应用进程JAR包依赖独立服务进程对外暴露端口应用接入替换DataSource代码侵入小应用无感知像连数据库一样连接性能开销本机计算网络链路短开销极低多一跳网络极端高并发下有额外延迟语言支持仅Java应用提供JDBC接口任何支持数据库协议的语言都能接入运维成本跟随应用发布依赖应用本身监控需要独立运维但配置变更可独立发布连接治理每个应用实例都保有自己的连接池集中管理连接数据库端连接数压力小独立管理面无配置在应用侧有支持DistSQL在线查看修改规则团队协作需要研发懂分片规则DBA也能操作规则职责边界更清晰事务支持LOCAL/XA/BASE事务均可XA/BASE需配合注册中心手动指定事务类型这张表不能只看技术字段还要落到团队协作上。JDBC形态把配置写死在应用代码或配置文件里意味着每次调整分片规则都要重新发布应用。Proxy形态通过DistSQL可以做在线规则变更DBA敲一条命令就能加一张分片表。这个差异在运维组织架构上很敏感决定了到底谁来负责这个中间件的日常维护。1.2 选型判断从流量规模、团队构成和应用边界倒推我个人选型的逻辑从来不是哪个更流行而是先问三个问题应用是什么技术栈、数据库连接压力当前是多少、规则调整频率会有多高。如果你的系统是纯Java技术栈业务规模在中等水平分片规则相对稳定那么ShardingSphere-JDBC是最合适的选择。它省掉了独立中间件的部署和军演成本性能开销最小。尤其适合那种对延迟非常敏感的在线交易链路比如电商下单、支付回调、库存扣减。这些场景本身就是Java系Spring Boot应用JDBC形态丢进pom.xml就可以工作链路短故障点少。如果你的系统不是纯Java比如有Python脚本、Go服务甚至数据分析平台也要访问分片后的数据那JDBC形态就会非常别扭。总不能每个语言都去维护一套ShardingSphere客户端配置。这种情况就是要上Proxy把分片能力和具体编程语言解耦任何能通过MySQL或PostgreSQL协议连库的客户端都能分片访问。还有一类信号也倾向于Proxy数据库主库的连接数已经偏高而你的应用服务实例又比较多。比如30个Pod各持有30个连接的连接池就是900个连接压在数据库上MySQL默认max_connections通常只有几千加上其他业务系统分走一部分很容易触顶。JDBC形态下每个应用实例都会占用真实连接而Proxy形态下应用只连ProxyProxy内部对数据库做连接复用数据库侧连接数能压缩一个数量级。从团队协作角度看如果贵司DBA团队愿意且有能力承担中间件运维职责选Proxy能明显释放研发侧压力。DBA可以直接通过DistSQL查看每条SQL被路由到了哪个分片做读写分离的流量切换也无需研发发版。反过来如果运维资源薄弱规则还得由研发维护那JDBC的轻量优势就非常突出因为根本不存在一个额外的服务需要你盯监控、做重启、保高可用。1.3 折中方案两种形态并存也没那么复杂不少大团队最终会走JDBC为主、Proxy为辅的混合路线这个组合工程上完全可行因为他们底层是同一套内核。核心业务Java应用用JDBC形态嵌入保证链路性能和最小改动外围非Java应用、BI报表、运维脚本走Proxy形态访问同一套分片数据。我在一个实际项目里就见过这种双形态并存订单中心5个核心应用全部接入ShardingSphere-JDBC数据同步任务和报表平台则连Proxy两边看到的物理表分布完全一致规则通过同一套版本化配置管理。Proxy用同一套分片算法配置启动没有出现任何规则漂移的问题。混合部署唯一要注意的是两边的规则版本必须保持一致否则路由结果会有偏差所以规则配置一定要纳入版本管理发布过程做好审批校验。2. 分库还是分表边界判断不是拍脑袋是算出来的分库分表边界这几个字被问到的频率最高但很多人把精力花在了配置怎么写忽略了最核心的判断——什么样的表才需要分片以及到底该分库还是分表。判断错了后面全是白忙。2.1 先明确一个基本原则分表解决访问性能分库解决资源瓶颈分表和分库解决的问题层次完全不同。分表解决的是单表数据量过大导致的B树索引层数加深、查询效率下降、DDL锁表时间变长、写放大等问题。一张表的数据量从百万涨到千万再到亿级索引层级会从三层往四层发展随机IO次数上升查询性能曲线是阶梯式恶化的。通过分表把数据拆进多张相同结构的物理表每张表的数据量能压到一个可控水位索引深度自然回落单条SQL的扫描范围也大幅收窄。分库解决的是数据库实例级别的资源瓶颈包括CPU、内存、磁盘IO、网络带宽以及连接数。分表之后数据还是在同一个库实例里如果这个实例本身的硬件资源已经被打满比如磁盘IO持续100%或者CPU跑满那么分表是救不了的。这时候必须分库把压力分散到多个实例上。判断哪种信号先出现基本就决定了优先做分表还是分库。我总结了一个判断清单比较实用信号优先方向判断依据单表行数超过1000万且仍在增长分表索引层数加深查询效率下降明显单表容量超过50GB备份恢复变慢分表物理表过大DDL和备份成本不可控慢SQL集中在单张表CPU/内存还够分表瓶颈在数据组织方式不在实例资源实例CPU打满所有业务整体变慢分库资源瓶颈在实例任何单表拆解都无法缓解连接数耗尽DBA强制杀连接分库连接资源是实例级别的分表无法解决磁盘IO延迟升高主从延迟放大分库物理资源到了上限需要水平扩展不同业务模块互相影响都想抢资源分库按业务域隔离天然适合库粒度拆分如果你同时看到单表涨到1500万和CPU接近70%两个信号我的判断顺序通常是先扩容实例资源或者先做读写分离把实例负载降下来再做分表解决单表查询问题。因为分库的改造阵痛远大于分表涉及分布式事务、跨库汇总、全局ID这些问题能晚做就晚做。当然这只是一个经验性优先级真正动手前还是要用业务峰值流量、数据增长速率、P99延迟目标这些数据一起做一道完整推演。2.2 分片表、广播表、绑定表和默认数据源表分类是第一步元数据设计一个数据库里几十上百张表不可能全部分片。分片是有代价的跨分片JOIN被禁止、分布式事务产生、聚合查询需要归并、主键不能再用自增。这些都是附加成本所以分片对象的选定需要甄别划分。按ShardingSphere的规则模型业务表可以分为四类我一次说清楚分片表是真正需要拆分的表比如订单表、订单明细表、流水表。这类表的共同特征是数据量增长快、访问有明显的分片键维度。比如订单表基本上都是按用户或买家维度查询少数后台按订单号倒查。广播表指的是所有分片数据源里都存在、内容和结构完全一致的表比如数据字典、区域表、渠道表。广播表在所有分片库中各保存一份完整数据写入时同步写所有分片读取时从任意分片读取。这样做的价值在于避免跨分片的JOIN比如订单表关联区域表如果区域表只在某个库里JOIN就会跨库。而每个分片库都有一份完整的区域表时JOIN就能在本库内部完成。绑定表是具备一致分片键关系的分片表集合。比如订单表和订单明细表都按order_id分片那么order_id10001的订单和它的明细永远落在同一个分片上。这样两者JOIN就不会跨分片也不需要广播表那种做法直接本库内JOIN即可性能表现接近非分片场景。默认数据源承载的是不需要分片的普通表比如后台管理系统的用户表、日志收集表如果它们量不大就统一放到默认数据源里。ShardingSphere路由时遇到未配置分片规则的表会自动路由到默认数据源不会强制要求所有表都纳入分片管理。我做一个分片设计时第一步不是写配置而是把全量表清单拉出来逐个标注属于哪一类。这个动作看上去繁琐但它直接决定了后面配置文件的复杂度和SQL兼容性风险。跳过这一步直接写分片规则几乎一定会遇到某张表没配分片但是被路由了或者某张普通表查询报错Table not found这类问题。2.3 分片键与分片算法路由结果是可以预判的分片键选得对不对直接决定整个分片方案是开了挂还是给自己挖坑。分片键选错最典型的翻车场景是按照order_id分片但业务上90%的查询是拿着user_id来查订单于是每次查询都要全路由到所有分片性能退化到比不分片还差。选分片键主要有三个约束条件按优先级排序第一保证查询覆盖率。分片键必须出现在高频查询的WHERE条件里而且最好是等值查询。对订单系统而言user_id通常是最常见的选择因为C端查询几乎全部按用户维度进行。第二保证数据均匀性。分片键的取值分布要相对均匀。尽量避开有明显热点或倾斜的字段比如按渠道字段分片可能某个渠道的数据量占据80%造成分片数据严重不均衡。第三尽量天然分布。比如user_id、order_id这种业务主键本身就是随机或类随机的取值做hash取模天然均匀。但按地区ID分片就会出现明显的热点问题因为某几个地区的用户量能把对应分片打爆。分片算法方面生产环境最常用的是hash取模和Range范围分片两种。hash取模的思路是分片键的值经过hash函数计算后对分片数取模得出分片编号。我用一个最简单的例子说明假设有4个分片某个订单的user_id取模后得到2那么这单就会落到user分片2对应的库或表。它的最大问题是扩缩容时模数变化导致大量数据迁移从4个分片扩到6个分片几乎每个键的映射都会改变。规避思路是一开始把分片数设为2的幂次扩容按倍数扩或者使用一致性哈希把影响范围控制在邻近区间。Range分片是按分片键的区间划分数据比如按月份分表或者按id范围分成若干区间。优点是扩容非常方便新增一个区间即可数据不用迁移缺点是高并发下最新区间会形成热点写压力全集中在一个点上。它更适合时间维度或数据访问有明显冷热之分的场景比如订单归档表、日志表。ShardingSphere的配置里有两种典型表达方式inline模式适合简单的取模或字符串hash表达complex则可以配置多个分片键做复合分片hint则是绕过SQL、由代码显式指定目标分片。我实际项目中90%的场景用inline就能解决但要注意inline用的是Groovy表达式分片键类型如果是字符串需要调用字符串hash方法不要直接拿字符串做取模运算否则路由结果会让人摸不着头脑。举一个我压测时验证过的具体例子user_id是Long类型分片总数是4那么分片编号就是user_id % 4。如果user_id20241217取模结果是1那么这条记录会落在编号为1的分片。如果分片键是字符串类型的订单号ORD20241217001则应该是ORD20241217001.hashCode() % 4。ShardingSphere的inline表达式写法就是order_id % 4或者order_id.hashCode() % 4它会自动识别字段类型走不同计算分支。2.4 分片数量规划一个可以提前算清楚的账分片数量拍脑袋是常见失误点。我曾经见过一个项目把订单表分成1024个分片理由是以后不用扩容了。结果分片过多导致每个分片的连接数被摊薄数据库连接资源浪费严重很多小分片几乎没数据管理成本反而上来了。比较合理的方式是根据当前数据量和未来3年增长预期来倒推。假设当前订单表有8000万行月增长800万3年后大约是3.68亿行。目标单表行数控制在1000万左右单表数据量控制在1000万到2000万行之间相对安全那么最终需要拆分成大约24张物理表。再考虑每张表预留一定缓冲直接取32张表也就是2的5次方这样也方便后续扩容时按倍数翻。分库数量的规划思路类似主要看写并发和连接数。假设线上单库峰值写TPS为8000单库的合理写容量按5000 TPS评估那么至少拆2个库才能扛住峰值。再结合高可用需求留余量拆4个库是更稳妥的选择。最终得到4库x8表的方案即每个库8张物理表总表数32张。如果后续要扩容从4库扩到8库每个库的表数量会变化但因为总表数是2的次幂迁移范围可以控制在一半以内。这个计算过程没什么高深理论就是把增长趋势和目标单表水位对齐。关键是给出的数字要有依据评审时能说出来为什么是4库8表而不是随便填的。3. 分片与读写分离联动配置逐行拆解与路由行为验证很多人分片配置能跑通读写分离配置也能跑通但把两者合在一起配置之后就各种诡异现象写流量出现在从库、读流量全压主库、事务内读走了从库读到旧数据。这些问题本质上都是因为没搞清楚ShardingSphere的规则优先级和路由细节。3.1 逻辑拓扑与物理拓扑的对应关系先理清一个基础概念。ShardingSphere的配置里逻辑数据源是我们自己在配置文件中定义的名字比如ds_0、ds_1。每个逻辑数据源可以指向一个物理库也可以指向一个读写分离组。当分片和读写分离联动时分片规则里的actualDataNodes写的不再是物理库名而是读写分离组的名字。比如我定义了两个读写分离组group_0和group_1每个组里有主库和从库那么分片规则要写成这样dataSources: group_0_write: url: jdbc:mysql://192.168.1.10:3306/sharding_db_0 username: root password: root group_0_read_0: url: jdbc:mysql://192.168.1.11:3306/sharding_db_0 username: root password: root group_1_write: url: jdbc:mysql://192.168.1.20:3306/sharding_db_1 username: root password: root group_1_read_0: url: jdbc:mysql://192.168.1.21:3306/sharding_db_1 username: root password: root rules: - !READWRITE_SPLITTING dataSources: group_0: writeDataSourceName: group_0_write readDataSourceNames: - group_0_read_0 loadBalancerName: round_robin group_1: writeDataSourceName: group_1_write readDataSourceNames: - group_1_read_0 loadBalancerName: round_robin注意这里的细节逻辑数据源group_0在YAML里并不是作为顶级dataSources存在而是由READWRITE_SPLITTING规则自动注册的。应用接下来可以直接使用group_0这个数据源名背后它会自动把写操作路由到group_0_write把读操作路由到group_0_read_0。然后在分片规则中引用这个逻辑数据源- !SHARDING tables: t_order: actualDataNodes: group_${0..1}.t_order_${0..1} databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: database_inline tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: table_inline核心就是把分片规则中的实际数据节点group_${0..1}直接指向读写分离组。ShardingSphere内部会先按数据源维度路由到group_0或group_1然后再根据SQL读写类型在对应的读写分离组内部选择主库或从库。3.2 分片路由和主从路由的执行顺序理解路由执行顺序非常关键。ShardingSphere收到一条SQL后先做分片路由判断这条SQL应该落到哪个分片库和分片表也就是先确定数据源维度然后进入数据源内部的主从路由根据SQL类型选择主库还是从库。举一个实际SQL例子来说明SELECT * FROM t_order WHERE user_id 20240101 AND order_id 80001。这条SQL的WHERE条件同时包含了user_id和order_id分片引擎根据databaseStrategy使用user_id取模定位到具体分片库再根据tableStrategy使用order_id取模定位到具体物理表。定位完成后ShardingSphere发现这条SQL的最终目标是某个分片库如果这个分片库配置了读写分离就会进一步判断这是SELECT走从库。如果SQL是INSERT INTO t_order (...) VALUES (...)经过分片路由后进入主从路由阶段由于是写操作强制走主库。这个两级路由的顺序意味着读写分离的判断是在分片判断之后执行的。也就是说分片规则真正的路由目标是一个包含了主从关系的逻辑数据源而不是一张具体的物理表。理解了这层关系就能解释为什么配置读写分离时必须在分片规则的actualDataNodes里用读写分离组的名字而不是物理主库的名字。很多新手在这里写错分片规则直接指向了group_0_write这种物理数据源结果SQL全部打到主库从库完全没流量读写分离形同虚设。还有事务场景也要注意。当一个方法上标注了TransactionalShardingSphere会在事务开启时把当前线程的连接绑定到特定数据源上此后这个事务内的所有SQL哪怕是SELECT也会强制走主库。这是为了避免读从库读到主库还未同步完成的旧数据。这一点在Spring Boot工程里尤其容易被忽略排查方式是在日志里观察事务边界一个事务内的SELECT是否全部走了主库。3.3 强制路由读主库的合理场景与实现方式读写分离的核心受益场景是读多写少把查询压力分散到从库。但架构上有一个天然的坑主从复制是有延迟的。MySQL默认的异步复制延迟通常很低但在大事务、DDL、从库负载过高的情况下延迟可能飙升到秒级。这时候就会出现业务上的经典问题用户下单成功后立刻请求订单详情查询被路由到从库而从库还没同步到这条刚插入的订单结果前端立刻提示订单不存在。这个问题的本质不是数据丢了而是读写一致性被主从延迟打破了。应对方案有两种一种是接受最终一致性前端加一次重试或者手动刷新另一种是在关键链路强制路由主库。两者不矛盾通常在强一致场景使用后者。ShardingSphere提供HintManager机制来强制主库路由。在需要强制路由的代码块中显式声明try (HintManager hintManager HintManager.getInstance()) { hintManager.setWriteRouteOnly(); // 这里执行的SELECT会强制路由到主库 OrderDO order orderMapper.selectByOrderId(orderId); }这个机制的原理是给当前线程打上一个本次请求强制走主库的标记从而让主从路由阶段不再进行负载均衡选择直接把SQL发往主库。但这里有个常见的坑HintManager的绑定范围是当前线程如果使用了线程池、异步编排或者Spring的Async注解Hint标记不会自动传递到新线程子线程里执行的SQL又会重新走读写分离逻辑。我的经验是在订单提交后的立即查询订单详情这个接口里整个链路都用同一线程执行必要时去掉异步化以确保Hint标记始终有效。除了代码层控制ShardingSphere也支持在配置中为某些特定SQL设置规则比如将某些表的查询强制路由主库。不过这种全局配置不够灵活我一般不用按业务方法粒度做Hint反而更可控。3.4 从库负载均衡策略轮询不是唯一选择读写分离配置里有个loadBalancerName字段很多人直接写round_robin就不管了默认是轮询。但在实际生产环境从库之间的硬件配置可能不完全一致或者某个从库还要承担其他线下分析任务轮询策略就会把流量均匀打到每个从库上可能造成慢节点拖累全局。ShardingSphere的负载均衡策略主要有round_robin、random和权重自定义几种。round_robin适合从库规格一致的场景random适合流量随机性要求高、从库分布较散的情况。权重自定义通常是基于从库的硬件规格- !READWRITE_SPLITTING dataSources: group_0: writeDataSourceName: group_0_write readDataSourceNames: - group_0_read_0 - group_0_read_1 loadBalancerName: read_balance loadBalancers: read_balance: type: WEIGHT props: group_0_read_0: 2 group_0_read_1: 1这里配置的含义是group_0_read_0获得2/3的读流量group_0_read_1获得1/3适合两个从库规格不同比如一个8C16G、一个4C8G的混合场景。权重值需要通过压测数据来定不要拍脑袋一般是根据历史CPU利用率和IO延迟做归一化折算。3.5 广播表和绑定表在联动配置中的处理当分片和读写分离联动时广播表和绑定表的配置同样要引用逻辑数据源。广播表的配置是这样- !SHARDING broadcastTables: - t_dict_region - t_dict_channel它会被自动复制到所有分片库中。当有读写分离组时ShardingSphere会把广播表写入所有分片库的主库读取时在各个分片库内按主从路由规则选择从库或主库。也就是说广播表在每个分片库里都有一份完整副本从库里的广播表数据由数据库自身的主从复制来保持同步不需要ShardingSphere额外处理。这个机制上线时验证一次就很容易理解但真正设置时要确认所有物理库的主从复制关系已经正常建立否则可能会出现主库有字典、从库没字典的诡异报错。绑定表配置更简单它不需要单独指定物理表只需要声明哪些分片表拥有相同的分片键规则- !SHARDING bindingTables: - t_order, t_order_item这个声明的意义在于告诉ShardingSpheret_order和t_order_item的分片键一致join它们时不需要做跨分片归并直接在同一分片中完成。这里暗含一个要求两张表的分片算法必须完全一致否则绑定了也没用甚至可能路由到错误分片。我曾踩过这个坑t_order按order_id % 4分表t_order_item按order_id % 8分表绑定后部分JOIN查询数据对不上。后来统一都把分片数改成4问题消失。3.6 压测验证如何确认流量真的按预期路由配置完成之后不能只看日志说启动成功就认为搞定必须通过流量验证确认路由是正确的。我惯用的验证方法是双管齐下。第一招打开ShardingSphere的SQL日志。在配置文件中开启sql.showprops: sql-show: true这条只适合开发测试环境生产环境确认没问题后要立即关闭因为日志量太大。开启后ShardingSphere会在日志里打印原始SQL和改写后的实际SQL以及路由到的数据源。比如你执行一条按user_id查询订单的SQL日志会显示Actual SQL: ds_0 SELECT * FROM t_order_0 WHERE user_id ? AND order_id ?其中的ds_0就是分片路由后的逻辑数据源。如果ds_0是配置了读写分离的组名你可以在MySQL的从库上执行SHOW PROCESSLIST来观察是否有来自应用的连接正在执行查询。也可以在从库的general_log里看是否出现对应的SELECT语句。第二招模拟主从延迟场景。手动在从库上停掉复制线程或者用一个大事务拖慢从库同步然后触发一次下单后立即查询订单的请求。如果强制路由主库的Hint生效这个请求依然能查到最新订单如果走了从库就会复现查不到订单的问题。这个验证步骤价值很高能提前发现代码里那些你以为走了主库但实际上走了从库的漏洞。4. 联动架构上线后踩过的坑与排查经验配置能跑通只是第一步真正折磨人的是上线后的各种隐性坑。我把踩过且花过不少时间排查的问题集中列出来能帮你省掉至少一个通宵。4.1 绕过ShardingSphere的隐秘连接这是所有分片架构里最隐蔽的风险之一。业务代码里的SQL不可能全都经过ShardingSphere数据源总有人为了图方便注入了一个原生DataSource或者写了定时任务直接使用了JDBC URL或者DBA在管理后台直连了某个物理分片库做数据修正。这些连接绕过中间件的路由引擎直接打到物理库的表上会造成数据不一致和主从断裂。这类问题很难从应用日志里发现我排查过的case基本都是因为订单状态对不上才暴露出流量绕行的。需要做的是提前在架构层面约定所有访问数据库的入口必须走统一的数据源门面禁止在业务代码里直接构建新的DataSource连接。同时在代码仓库规范里加入连接使用审计项定期扫描是否存在绕过数据源的代码。4.2 分布式事务的边界控制分库之后一个业务操作可能会跨多个物理库执行写操作这时本地事务就失效了。ShardingSphere提供了几种事务类型LOCAL、XA、BASE。LOCAL就是普通本地事务适合单分片内的写操作。XA是基于标准两阶段提交的强一致事务适合对一致性要求极高的场景但性能开销和实现复杂度偏高。BASE则是柔性事务典型实现是SEATA AT模式的集成牺牲强一致换取性能和可用性。我的经验是尽量避免在代码里显式使用分布式事务从设计层面规避跨分片事务的触发场景。比如一个下单流程涉及订单表和库存表如果把库存也按用户ID分片那么同一用户的订单和库存大概率在同一个分片上事务仍然是本地事务。如果必须跨分片优先评估XA还是BASE。X A的开销在主链路高并发场景下往往不可接受需要提前做压测验证BASE适合对短时不一致要求不高的场景比如余额变更后允许一段时间内的查询延迟可见。4.3 分布式主键生成的坑分库分表后数据库自增主键完全不可用因为多个分片各自从1开始自增会产生重复的全局主键。ShardingSphere内置的分布式主键生成器添加了snowflake算法配置方式是在分片表规则中加入keyGenerateStrategy- !SHARDING tables: t_order: keyGenerateStrategy: column: order_id keyGeneratorName: snowflake这里有个性能上的冷门注意事项ShardingSphere默认使用Java的System.currentTimeMillis()作为时钟源。如果服务器进行了时间回拨比如NTP同步导致时间跳到过去snowflake在极端情况下可能生成重复ID。应对方式是在部署时开启NTP的slewing模式避免大步进时间回拨同时在应用层监控ID冲突告警。另外分布式主键最好保持long型和数据库的bigint对应避免前端精度丢失问题。这一点容易被忽略特别是如果分片键恰好就是主键生成方式会直接影响后续的所有路由计算。4.4 动态扩容的提前规划分片方案里最怕的是上线一年后发现分片数不够要扩容。扩容改分片数会导致取模结果全部变化几乎等同于全量数据重分布。虽然ShardingSphere支持自动迁移工具但这依然是一件高成本、高风险的事情。我建议在最初设计时就做一个保守规划按3年数据增长量估算出分片数再乘上1.5的缓冲系数。比如算出来需要24个分片我可能直接上32个分片宁可在前期多放空槽也不要中途大规模扩容。如果真的要扩容有两种常见策略一种是一致性哈希扩容时只迁移部分数据另一种是Rangehash两级路由先用日期或用户区域做一级路由固定范围再在范围内做hash取模翻倍出新的分片数后只需要对新增范围进行数据迁移。这个方案能显著降低迁移成本代价是路由规则稍复杂对配置编写和排障都不太友好。在Proxy形态下ShardingSphere提供Scaleout分布式扩缩容能力支持在不停机的情况下做数据迁移和流量切换。这对于在线业务来说价值很大。JDBC形态则没有独立的扩缩容工具只能依赖应用发版调整配置所以如果你预期未来数据增长非常迅猛选Proxy形态在扩容这个维度上会占优势。4.5 连接池配置和参数调优分片和读写分离联动后单个应用实例需要维护的连接数会明显变多因为逻辑数据源变多了。如果配置了4个分片组、每个组有主从两个库那么连接池里的连接数量就翻了8倍。连接池参数如果沿用之前的设置容易导致数据库连接数被打满。我的调优思路是把最小空闲连接数调低把最大连接数控制在一个合理范围同时从库的连接优先复用。比如原来单库连接池配置了最大50分片后4个分片、每个分片主从库各一个池最大连接数可以控制在每个池20附近总数仍然可控。具体数值和数据库规格、应用并发数强相关需要压测动态调整但一开始就要意识到连接数总量会比单库场景大很多。另外建议每个逻辑数据源都单独配置连接池参数。在ShardingSphere里可以用props方式统一设置也可以针对特定数据源覆盖。不要图省事全局一个参数因为主库和从库的负载特性很可能不同。4.6 一个完整排查链路示例从订单查不到到定位主从延迟最后用一个真实排查case复盘一遍完整链路能帮你理解上面这些点如何串联起来。现象是压测环境下用户完成下单后立刻刷新订单列表偶尔会出现订单不存在的提示概率大约2%。这个问题在功能测试阶段几乎不出现但压测一上来就明显了。我当时的排查路径是这样走的。第一步先确认订单数据是否真正写入主库。通过日志中打印的实际SQL确认INSERT语句确实发送到了group_0_write数据库主库里也查到了这笔订单记录。第二步确认这个查询SQL的路由目标。打开SQL日志发现查询语句被路由到了group_0_read_0说明读写分离生效了但正是这个生效暴露了问题——这就是主从延迟导致的读旧数据。因为压测请求在极短时间内连续触发写入和读取从库还没来得及同步这条新订单。第三步查看主从延迟状态。在从库执行SHOW SLAVE STATUS发现Seconds_Behind_Master稳定在几十毫秒到几百毫秒之间。虽然绝对值很小但压测下请求间隔可能只有几十毫秒所以仍然会出现读不到新数据的窗口。第四步确定修复方案。由于订单创建后的立即查询属于强一致需求不能接受最终一致性所以决定让这个阅读接口强制走主库。通过HintManager做writeRouteOnly标记打开SQL日志再次验证确认强制路由后这条查询被路由到了group_0_write字段问题消失。这个排查链路的启示是不要一看到订单不存在就怀疑数据丢了或者分片路由错了先确认主从延迟这个隐形变量。特别是压测和活动高峰期主从同步延迟的波动会明显放大这类问题。日常监控里把主从延迟指标纳入告警范围秒级延迟就要关注超过1秒必须立刻处理。如果业务对一致性要求高干脆把关键查询接口的写后读场景全部做成强制主库路由这也是我最终推荐的做法。5. 一些配置之外的补充建议分片方案一旦上线数据分布和物理表结构就基本固化了再改的代价非常大。所以有几个配置之外的问题值得反复审视。关于数据迁移。无论是从单库迁到分片库还是从旧分片规则迁到新规则建议都用专门的迁移工具比如ShardingSphere提供的Scaling能力不要自己写脚本导数据。自写脚本的边界情况处理成本极高很容易漏数据或者重复导入。上线迁移时要做好前校验和后校验前校验保证源库数据完整后校验确认分片后的数据分布符合预期。关于压测和容量评估。分片架构一定要做全链路压测但压测的时候要确保数据分布和线上一致不要用一个数据量只有100万但分片数却按1亿规模配置的库来测。数据量太少时单分片的性能表现和真实高数据量下完全不同压测结论可能误导容量规划。关于代码维护规范。分片配置、广播表清单、分片键定义这些一定要沉淀成文档并且在代码评审时逐项对照检查。我见过最离谱的情况是新来的同事在业务代码里直接写了一条不带分片键的全表扫描SQL整个系统所有分片库被打了一遍数据库IO瞬间飙满。分片键缺失时的全路由行为是一个高风险点如果业务上确实存在必须全路由的查询场景建议通过配置显式允许并评估好性能兜底而不是让它无感知地发生。这套架构跑到现在整体稳定性是让人放心的。每次业务高峰期看监控面板上各分片的路由流量相对均匀、主从两端的读负载正常分担就能感觉到早期在选型和边界判断上花的时间没有白费。如果你现在的数据量也到了单库开始吃力的阶段建议先拿出一张纸把核心表的数据增长趋势和查询模式写出来再做一次测算然后再打开配置文件动手。数据库路由这种底层改动慢就是快。