企业官网建设流程全解析

附-02 · MySQL 分库分表与中间件 —— ShardingSphere / MyCat 分片策略实战

系列定位：《MySQL 数据库全栈运维实战系列》第 附-02 篇（番外），与《Oracle 数据库全栈运维实战系列（VMware 版）》同构对标。适用版本：MySQL 8.0（5.7 差异随文标注）。官方文档：Apache ShardingSphere 官方文档、MyCat 开源社区文档、MySQL 8.0 Reference Manual。

一、什么时候该分库分表

单表超过 2000 万行、单库 TPS 超过单机上限、或者业务按租户天然隔离时，才需要分库分表。分库分表是最后手段，不是银弹——它会带来分布式事务、跨分片 JOIN、扩容迁移、全局唯一 ID 一系列复杂度。能靠索引优化、读写分离、缓存解决的，先别分。

VMware 虚机环境注意事项：分片后的每个分片都是一台独立 MySQL 实例（或独立虚机），虚机数量线性增长。测试环境建议 2~3 个分片节点 + 1 个中间件节点，全部跑在 VMware 上。中间件节点（ShardingSphere-Proxy/MyCat）本身无状态，可双实例 + VIP 高可用。分片节点的磁盘要各自独立 VMDK，不要多个分片挤一块盘。

二、两大中间件对比

三、分片策略怎么选

分片键选择三原则：

1. 绝大多数 SQL 都带这个键（否则全分片广播，性能灾难）。
2. 数据分布均匀（别拿性别、地区做取模分片键）。
3. 尽量不更新（分片键改了要跨分片迁移行）。

四、ShardingSphere-JDBC 5.x 实战

4.1 Maven 依赖

<!-- pom.xml（解释：5.x 稳定版，spring-boot-starter 更省事） --> <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc-core</artifactId> <version>5.4.1</version> </dependency>

4.2 YAML 分片配置（t_order 按 user_id 取模分 4 片）

# sharding.yml（解释：4 个真实库 ds0~ds3，t_order 按 user_id 取模路由） dataSources: ds0: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db-shard-0:3306/order_ds0?useSSL=false&serverTimezone=Asia/Shanghai username: shard password: shard_pwd ds1: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db-shard-1:3306/order_ds1 username: shard password: shard_pwd ds2: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db-shard-2:3306/order_ds2 username: shard password: shard_pwd ds3: dataSourceClassName: com.zaxxer.hikari.HikariDataSource driverClassName: com.mysql.cj.jdbc.Driver jdbcUrl: jdbc:mysql://db-shard-3:3306/order_ds3 username: shard password: shard_pwd rules: - !SHARDING tables: t_order: actualDataNodes: ds0..3.t_order_0..16 databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: db_mod tableStrategy: standard: shardingColumn: order_id shardingAlgorithmName: table_mod keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: db_mod: type: MOD props: sharding-count: 4 table_mod: type: MOD props: sharding-count: 17 keyGenerators: snowflake: type: SNOWFLAKE

-- 业务侧无感知（解释：应用还是写 t_order，中间件自动路由） INSERT INTO t_order (user_id, order_id, amount) VALUES (1001, 20261009001, 99.5); -- ShardingSphere 自动算：user_id=1001 对 4 取余为 1 路由到 ds1；order_id 对 17 取余为 8 路由到 t_order_08 -- 实际落在 ds1.t_order_08

五、ShardingSphere-Proxy 实战（独立代理）

Proxy 跑在独立节点，应用把它当普通 MySQL 连。

# 下载启动（解释：5.x 发行包解压即用，默认 3307 端口） tar -zxvf apache-shardingsphere-5.4.1-shardingsphere-proxy-bin.tar.gz -C /opt/ cd /opt/apache-shardingsphere-proxy-bin/ # 配置 conf/server.yaml 和 conf/config-sharding.yaml（结构同 JDBC 版 YAML） ./bin/start.sh # 应用侧连 Proxy（解释：和连普通 MySQL 没区别） mysql -h proxy-node -P 3307 -u sharding -p

六、MyCat 1.6 配置（存量系统参考）

MyCat 1.6 的经典配置由 schema.xml 和 rule.xml 两部分组成。

6.1 schema.xml（逻辑表与数据节点）

<schema name="orders_db"> <table name="t_order" primaryKey="order_id" dataNode="dn1,dn2,dn3,dn4" rule="order-by-user-id"></table> </schema> <dataNode name="dn1" dataHost="host0" database="order_ds0"/> <dataNode name="dn2" dataHost="host1" database="order_ds1"/> <dataNode name="dn3" dataHost="host2" database="order_ds2"/> <dataNode name="dn4" dataHost="host3" database="order_ds3"/>

6.2 rule.xml（取模分片规则）

<tableRule name="order-by-user-id"> <rule> <columns>user_id</columns> <algorithm>mod-four</algorithm> </rule> </tableRule>

对应的分片算法定义在 rule.xml 的 function 段：name 为 mod-four，实现类是 MyCat 内置的取模函数 PartitionByMod（完整包路径 org.opencloudb.route.function.PartitionByMod），参数 count=4，即按 user_id 对 4 取余路由到 4 个数据节点。

注意：MyCat 1.6 已多年不维护，是 JDK 7/8 时代产物，新项目不建议选；存量维护可参考，新系统一律 ShardingSphere 5.x。

七、分库分表的四大坑

7.1 跨分片查询

不带分片键的 SQL 会广播到所有分片，性能差。

-- 带分片键：单分片路由，快 SELECT * FROM t_order WHERE user_id = 1001 AND order_id = 20261009001; -- 不带分片键：全分片广播，慢（解释：必须避免） SELECT * FROM t_order WHERE create_time >= '2026-10-01';

解决：这种分析类需求走 ES / 列式库 / 单独的报表库，不要在分片库上跑。

7.2 分布式事务

跨分片写订单 + 库存，本地事务保不住。

7.3 全局唯一 ID

自增主键在分库后会冲突。

7.4 扩容数据迁移

4 片扩到 8 片，取模规则变了，要重新分布数据。

工具：ShardingSphere-Scaling、DataX、自研迁移脚本。扩容期间必须双写 + 灰度切流。

八、类比 Oracle 速查

九、踩坑记录（实测汇总）

十、本文要点速记

1. 分库分表是最后手段：先索引、读写分离、缓存，顶不住再分。
2. 中间件选 ShardingSphere 5.x：Java 用 JDBC 嵌应用，异构用 Proxy；MyCat 只维护存量。
3. 分片键三原则：多数 SQL 带它、数据均匀、不更新。
4. 取模 vs 范围：等值查询取模均匀，时间归档范围易冷热分离。
5. 四大坑提前规划：跨分片查询、分布式事务、全局 ID、扩容迁移。
6. 扩容双写 + 校验：别直接切，灰度切流。

十一、参考资料（官方正式文档）

本文章属于《MySQL 数据库全栈运维实战系列》番外篇。欢迎收藏、交流。