分库分表是解决单库数据量过大、性能瓶颈的核心手段，下面通过一个电商订单系统实例，完整拆解分库分表的设计与实施步骤。
分库分表实例：从单库到多库的演进之路
我们团队负责的电商订单系统,早期订单量日均几千单，单库单表完全够用，随着业务增长，订单量突破百万级，单库出现查询慢、写入锁冲突、磁盘空间告急等问题，数据库CPU长期跑在80%以上，半夜的统计报表经常跑超时，这就是典型的分库分表业务场景：单库无法支撑高并发与大数据量，我们决定对订单系统进行拆分，从单库单表演变为分库分表架构。
拆前分析：找出瓶颈与拆分目标
- 性能瓶颈：订单表数据量超过5000万行，索引深度过大，写入和查询响应时间超过2秒。
- 扩展需求：业务预估未来一年订单量再翻两倍，单库无法通过垂直扩容（加硬件）解决。
- 拆分目标：将单库压力分散到多个数据库节点，提升读写吞吐量，同时保证业务逻辑不受影响。
拆分策略：垂直分库 + 水平分表
我们选择垂直分库切分业务模块，将订单库与商品库、用户库分离；水平分表将订单表按订单ID取模拆分到128个物理表中，垂直分库减少了跨业务干扰，水平分表控制了单表数据量。
分库分表怎么做：拆分策略与分片键选择
很多团队在问分库分表怎么做，关键是选对拆分策略和分片键，我们结合实例逐一说明。
垂直分库：按业务域切割
- 将订单、用户、商品、支付等模块独立成库，每个库只负责自己的领域。
- 优点：业务清晰，隔离性高，资源独立。
- 缺点：跨库关联查询变复杂，需要应用层或中间件整合。
水平分表：按某个字段分片
- 分片键选择：订单ID（主键），取模算法：
order_id % 128
- 为什么选订单ID：因为大部分查询都带订单ID（如订单详情、退款），不走库的查询会被拦截。
- 其他常见分片键：用户ID、时间，根据业务查询模式决定，避免跨库查询成为常态。
分片键选择原则
- 尽量选择查询频率高、分布均匀的字段。
- 避免使用数据倾斜严重的字段（如地区、状态）。
- 如果业务支持,可以设计复合分片键，但会增加路由复杂度。
分库分表中间件选型：ShardingSphere vs MyCat
选对中间件能降低分库分表落地难度,我们对比了主流方案，ShardingSphere-JDBC和MyCat。
功能对比
| 特性 | ShardingSphere-JDBC | MyCat |
|---|---|---|
| 架构 | 驱动层，嵌入应用，无独立服务 | 代理层，独立部署，对应用透明 |
| 性能 | 零网络开销，性能较高 | 多一层代理，有轻微损耗 |
| 分片能力 | 支持分库分表、读写分离、分布式事务 | 同样支持，但规则配置较复杂 |
| 社区活跃度 | 高，持续更新 | 近年更新较慢 |
我们选型决策
- 我们选择ShardingSphere-JDBC，因为团队熟悉Java，且希望降低运维复杂度（无独立服务）。
- 配置方式：通过YAML配置分片规则，指定分片键和算法。
- 关键配置示例：
actualDataNodes: ds$->{0..2}.order_$->{0..127}，表示3个库，每个库128张表。
数据迁移与扩容：分库分表落地实操
拆分规则确定后,数据迁移是最大的挑战，我们采用双写策略，确保新旧库数据一致。
迁移步骤
- 准备新库结构：按分片规则建好多库多表，初始化索引和约束。
- 开启双写：在代码层同时写入旧库和新库，老数据继续从旧库读取。
- 全量数据迁移：使用脚本分批将旧库数据导出，按分片规则写入新库，注意导出时记录分表，避免数据重复。
- 数据校验：对比旧库和新库的订单总数、关键字段哈希值，确保一致。
- 切换读流量：先灰度1%读流量到新库，观察性能与正确性。
- 全量切换：确认无误后，读写全部走新库，关闭旧库写入口。
扩容注意事项
- 如果后期需要增加分片数量,建议使用一致性哈希或混合分片，避免大规模数据迁移。
- 我们一次性预留了128个分片,未来3年不需要调整分片数。
分库分表常见问题：跨库查询与事务处理
分库分表后,跨库查询和分布式事务是绕不开的难题。
跨库查询解决方案
- 避免跨库查询：查询时尽量带上分片键，让路由直接定位到具体库。
- 无法避免时：在应用层手动聚合（如查多个库后内存合并），或使用中间件的广播表功能（如ShardingSphere的
broadcast-tables）。 - 对于全表统计,改用离线数仓（如Hive、ClickHouse）处理，避免对在线库造成压力。
分布式事务处理
- 我们采用BASE理论：最终一致性，配合可靠消息（如RocketMQ）完成订单与支付状态的同步。
- 对于强一致场景（如扣库存），使用Seata TCC模式，性能可接受。
- 业内专家指出,绝大多数电商业务，柔性事务比强事务更实用，且对性能影响更小。
分库分表业务场景：哪些情况建议拆分？
不是所有系统都需要分库分表,我们总结了几个典型场景。
适合分库分表的场景
- 单表数据量超过千万行,且持续增长，查询和写入性能明显下降。
- 数据库连接数或IOPS达到上限,无法通过读写分离解决。
- 业务未来有明确的高并发或大数据量规划。
不适合分库分表的场景
- 数据量小（百万级以下），单库单表无压力，强行拆分增加复杂度。
- 业务逻辑复杂,大量跨库关联查询且无法改造。
- 团队缺乏运维经验,建议优先考虑云数据库扩展（如TiDB、PolarDB）等分布式数据库方案。
分库分表常见问题解答
分库分表后如何保证数据一致性？
分库分表后,数据一致性通过可靠消息和补偿机制保证，我们采用本地消息表：写操作时，先记录消息到本地事务表，再通过定时任务异步发送到MQ，消费者消费后更新其他库，如果失败，有重试机制，核心是业务上接受最终一致性，并做好对账。
分库分表如何选择中间件？
如果团队熟悉Java,单机性能要求高，选择ShardingSphere-JDBC；如果希望应用无感知、多语言支持，选择MyCat或ShardingSphere-Proxy，选型时重点关注分片功能、社区活跃度、运维成本，我们实测ShardingSphere-JDBC在4核8G机器上，QPS可达2万+，满足大部分业务需求。
分库分表后如何扩容？
预留足够的初始分片（如128个库），避免频繁扩容，如果需要扩容，采用一致性哈希或双倍扩容策略：将原有分片数翻倍，数据通过一致性哈希重新分布，每次只迁移一半数据，扩容期间需要开启双写，逐步切换，实际中，我们通过预分配128个分片，3年内无需扩容，降低了运维风险。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/571433.html
