Spring Boot 3 + ShardingSphere-JDBC: One Configuration That Runs Read-Write Splitting and Sharding Together

ShardingSphere-JDBC collapses read-write splitting and sharding into a single JVM-level driver, so developers can keep writing ordinary SQL while the middleware owns routing. The trade-off is real operational overhead: you still create physical tables, maintain replicas, and design sharding keys carefully, and any miss on the key turns a fast single-table query into a broadcast across all shards.

A practical walkthrough wires read-write splitting and table sharding into a Spring Boot 3 application using ShardingSphere-JDBC 5.5.2. The middleware acts as an enhanced JDBC driver, not a separate proxy, and handles SQL parsing, routing, rewriting, and merging before any statement reaches MySQL. Business code keeps writing plain logical table names like `t_order`, while the engine rewrites them to `t_order_0` or `t_order_1` based on the sharding key.

The configuration in `sharding-ms.yaml` defines a write datasource and a read datasource, then groups them into a logical `readwrite_ds`. The sharding rule uses `user_id % 2` to distribute rows across two physical tables. A distributed primary key strategy via MyBatis-Plus's `ASSIGN_ID` replaces auto-increment to avoid collisions across shards. The guide also shows how `transactionalReadQueryStrategy: PRIMARY` forces reads inside a transaction to hit the primary, avoiding the "write then read stale" problem.

Verification steps demonstrate the routing logs, a batch insert that produces 1000 rows spread evenly across shards, and the performance difference between a shard-key query and a broadcast query. The author lists the operational caveats: physical tables must be created manually, master-slave replication is not handled by ShardingSphere, cross-shard pagination degrades sharply without a sharding key, and distributed transactions beyond a single shard are out of scope.