分库分表技术是解决单数据库性能瓶颈的主流方案，核心思路是将数据按规则拆分到多个数据库实例，从而提升系统扩展性和并发能力。 随着业务数据量从百万级增长到千万级甚至亿级，单库的存储和连接数限制越来越明显,分库分表成为许多技术团队必须掌握的关键能力。参考2
分库分表水平拆分和垂直拆分的区别是什么？
水平拆分：按行切分，同表结构不同库
水平拆分是最常见的分库分表方式，本质上是将一张表的数据行按照某个分片键均匀分布到多个数据库中，用户表按用户ID哈希分到16个库，每个库只存其中一部分数据，这样，单库的数据量总量减少，写入并发能力也线性提升。水平拆分的关键在于分片键的选择,它决定了数据是否均衡。
垂直拆分：按列切分，不同表拆分到不同库
垂直拆分是将一张表的不同列或不同表拆分到不同的数据库，将用户基础信息表和高频访问的日志表分开存放，或者将订单的头部信息和明细信息拆分，垂直拆分缓解了单库的存储压力，但无法解决单表数据量过大的问题,通常需要结合水平拆分一起使用。
两者如何选择？
- 如果单表数据量巨大，但列数不多，则优先考虑水平拆分。
- 如果单表列数多，字段宽，但行数尚可，则考虑垂直拆分。
- 多数情况下，两者结合使用：先垂直拆分（按业务模块分库），再水平拆分（按分片键分表）。
业内专家指出，水平拆分是解决单表数据量膨胀的核心手段,而垂直拆分更多用于业务解耦和读写分离场景。
分库分表中间件对比：哪个更适合你的业务？
目前主流的分库分表中间件包括ShardingSphere、MyCat、Vitess等,它们各有侧重。
功能对比表
| 中间件 | 模式 | 分布式事务 | 支持语言 | 社区活跃度 |
|---|---|---|---|---|
| ShardingSphere | 客户端/驱动 | 强支持 | Java为主 | 非常活跃 |
| MyCat | 代理层 | 有限支持 | 任何语言 | 较活跃 |
| Vitess | 代理层 | 强支持 | 任何语言 | 活跃 |
如何选型？
- ShardingSphere：适合Java技术栈，希望集成度高，对性能要求高的团队，它提供分库分表、读写分离、数据加密等多种能力。
- MyCat：适合多语言环境，需要透明代理的场景，部署简单,但性能不如客户端模式。
- Vitess：适合大规模集群，需要自动分片和调度能力,常与Kubernetes结合使用。
分库分表中间件的选择，关键在于你的团队技术栈和运维能力，如果追求轻量级，MyCat是不错的选择；如果拥抱云原生，Vitess更有优势。分库分表中间件对比时,还应考虑社区支持和文档完备性。
分库分表分片键怎么选？三个核心原则
分片键是分库分表的灵魂,选错了会带来严重的数据倾斜和查询效率问题。
分片键选择原则一：数据均匀分布
分片键的取值应尽可能散列，避免热点，用户ID很适合用哈希分片，而时间字段则容易产生写热点（集中在当前时间分片），通常采用一致性哈希或取模算法。
分片键选择原则二：常用查询条件
分片键应尽可能覆盖业务中主要的查询维度，如果查询经常按用户ID聚合，那么用户ID作为分片键就很合适，如果查询经常按订单ID，那么订单ID分片。分片键怎么选,需要结合业务查询模式。参考2
分片键选择原则三：避免跨分片查询
跨分片查询会损耗性能，因此分片键设计时应尽量让大多数查询落在单分片上，如果不可避免,则需考虑全局路由表或索引缓存。
分库分表分片键的选择，是决定方案成败的关键，行业共识认为，分片键应使用业务主键或高基数字段,避免使用枚举值。
分库分表数据迁移的实操步骤
从单库迁移到分库分表架构，需要谨慎执行数据迁移,确保数据一致性和业务连续性。
停机迁移
- 业务维护窗口,停止写入。
- 导出单库数据,按分片规则拆分导入多个库。
- 验证数据,切换数据源。
- 优点：简单，可控；缺点：需要停机时间。
双写迁移
- 在原有单库基础上,同时写新分库。
- 定期同步历史数据。
- 验证数据一致后，切换只读新库,再切换写入。
- 优点：无停机；缺点：代码需要改动,双写压力。
分库分表数据迁移，建议使用成熟的迁移工具，如ShardingSphere的迁移功能或canal+kafka方案，据统计，大多数互联网公司采用双写迁移方案,以减少停机时间。
分库分表常见问题与避坑指南
跨分片聚合查询的解决方案
分库分表后，跨分片的聚合查询（如COUNT、ORDER BY、JOIN）需要调用多个分片然后合并结果，常见的做法是采用全局聚合或中间层二次聚合，对于频繁的跨分片查询，可以考虑建立全局索引表或异构数据汇总。
分布式事务处理方案
分库分表后，涉及多个数据库的事务需要引入分布式事务机制，常用的方案有：TCC（尝试、确认、取消）、Saga模式、基于消息队列的最终一致性，对于金融级场景，通常使用Seata等框架。
全局主键生成策略
分库分表后，数据库自增ID不可用，需要全局唯一的ID，常见方案有：
参考2
雪花算法（Snowflake）、UUID、Redis incr、Leaf等。雪花算法是最常用的，64位ID，趋势递增,性能好。
分库分表实施成本与价格因素
对于中小企业，分库分表的实施成本包括：中间件部署（开源免费）、额外硬件资源（多台服务器）、开发维护人力。分库分表的价格主要体现在开发和运维投入，而非软件许可费用，如果考虑云服务，云厂家提供的分库分表方案（如DRDS）按实例收费,需根据接入量和存储量评估。
分库分表是在数据库层做水平扩展的成熟技术，但并非万能，它解决的是单库容量和并发问题，但会引入复杂度。设计时需结合业务特征，选择合适的分片策略和中间件，并做好数据迁移方案，只有充分理解其原理和代价,才能让分库分表真正成为系统扩展的利器。
分库分表技术常见问题解答
分库分表后，查询速度一定比单库快吗？
不一定，如果查询能命中分片键，在单分片上执行，确实变快；但如果查询条件不包含分片键，会导致全分片扫描，可能更慢。分库分表需要配合合理的索引设计和查询路由。
分库分表后如何进行跨分片分页？
跨分片分页需要先对所有分片的数据进行排序，再合并，常见做法是采用分片内取全量，服务端归并，或者使用中间件层聚合，对于有序分页，可以利用分片键的全局有序性来减少归并开销。
分库分表对业务代码的侵入性如何控制？
使用中间件（如ShardingSphere）可以低侵入地实现分库分表，开发人员只需配置分片规则，代码层面几乎无感知，但复杂的跨分片事务和查询仍需业务层面配合，整体侵入性取决于分片粒度。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/534178.html
