37 | 什么时候需要分表分库？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了在当今互联网时代，海量数据处理中的分表分库优化方案。随着移动互联网产品中海量数据的不断产生，优化存储能力成为关键。文章指出了在单表单库情况下，随着数据量的累积，数据库性能会下降，因此分表分库成为提升数据库并发处理能力、整体性能的重要手段。文章详细介绍了分表分库的实施方式，包括垂直切分和水平切分，以及分表分库后面临的问题，如分布式事务问题和跨节点JOIN查询问题。此外，文章还探讨了跨节点分页查询、全局主键ID、扩容等问题，并提出了解决方案。总之，分表分库虽然存在各种问题，但在海量数据、高并发的业务中仍是最常用的优化手段。文章通过分析海量数据的特点，提出了分表分库的优化方案，为读者提供了解决海量数据存储和处理问题的思路。同时，文章还介绍了分表分库的实施方式和面临的问题，为读者提供了实用的技术指导。
《Java 性能调优实战》，新⼈⾸单¥59
全部留言(31)
- 最新
- 精选
- mmilan老师说"我们在最开始设计表数据量时，尽量使用 2 的倍数来设置表数量。当我们需要扩容时，也同样按照 2 的倍数来扩容，这种方式可以减少数据的迁移量"，不是很理解为什么按2的倍数，就能减少数据的迁移量？
作者回复: 我们的分表一般是根据[字段的hash值%表数量]或来进行分配的。 假设某分表字段的哈希值4、8、12，原来的表数量为4，所以这几个数据都会在一个表中。当扩容到8时，只有12会迁移到第五张表中。 如果扩容到6张表的话，此时哈希值为4的数据会迁移到第五张表，哈希值为8的需要迁移到第三张表，只有哈希值为12的不需要迁移。
2019-08-281133 
Jxin
1.中间件应该就mycat，sharding jdbc应该属于基础框架来使用。 2.提个问题，公司禁用分区，不知为何，但结果就是相关知识忘光光。本章刚好也有提到，顺带麻烦老师介绍下分区，这块反而成薄弱点了。作者回复: MySQL的表分区存在一些限制，常见的有：分区字段不能为NULL，避免建立和分区列不匹配的索引。 除此之外，底层实现的表分区，对MySQL来说其实是一个性能消耗的过程，特别是范围分区，服务器需要扫描所有的分区定义的列表来确定具体的分区。 表分区在操作数据过滤之前，是需要打开并锁住所有底层表的，这个过程是在分区过滤之前发生的，所有是一个非常消耗性能的过程。 分区表的维护成本也是很高的，特别是重组分区。 总之，MySQL的表分区实现偏底层，定制不灵活且性能不是很好，维护成本高。所以很多DBA不建议使用。
2019-08-2216
QQ怪现在Fescar已经改名为Seata作者回复: 看来成长比较迅速呀。这个开源中间件比较新，去年刚开源的时候了解下源码，顺便实践了基本功能。
2019-08-1515
珠穆写码老师，可以用tidb这种newsql取代分库分表的方案吗作者回复: 可以的，TiDB是一种集中式的数据存放解决方案，可以节省开发人员很多工作量。
2019-08-1510
.数据冗余后，如果数据修改后数据更新怎么方便点？作者回复: 一般冗余数据前提是不频繁被修改的，甚至更严格为不会变修改的数据才能坐数据冗余
2020-03-219
儿戏老师，请问下 订单表用 用户ID 做hash 分库分表后，订单的item表会成倍增长，造成的数据倾斜，怎么解决？做2次分表吗？作者回复: 一般我们都是采用hash求余的方法来实现分库分表，如果在生产环境中出现数据倾斜比较严重，我们需要考虑使用一致性hash算法实现分库分表，也是二次分表的一种实现，只不过可以对局部倾斜数据进行二次分表，实现起来方便，且只影响部分表数据。
2019-09-056
Mr.wang刘老师，这里我不太了解一个表字段非常多的时候，新增会发生跨页问题，除了老师在上一章中讲到mysql主键id不是自增id，在新增的时候会发生跨页的原因，这里的跨页还有其他原因吗？作者回复: 数据页的大小是有限的，如果插入行数据大于数据页大小，就会发生跨页问题了。
2020-03-125
钱我使用过公司基础架构部自研的数据库中间件，对于分库分表的的数据查询可以动态路由，不过也就是动态路由，对于join的支持有限，另外分布式事务保证的也一般般。不知开源产品中有哪些佼佼者，功能多性能高?作者回复: sharding-jdbc\mycat在行业内使用比较多，各有优势
2019-09-153
皮卡皮卡GitHub上搜snowflake已经淘汰了作者回复: 可以自我实现一个snowflake工具类，理解雪花算法的原理即可
2019-09-262
许童童我们的系统前期没设计好，现在想分库分表很难，大量join查询，很难处理。 想用阿里云的分页式rdbms，不知道可行性。作者回复: 前期没有做好分表的准备，后面做表升级工作量就大很多，而风险更高。 例如一个表如果是自增主键ID，而主键ID又跟其他业务表做了耦合，当我们要做表升级时，需要用另外一个字段做分表字段，这时候就存在主键ID在分表后可能存在冲突的问题。 所以一开始我们就要想到这张表有可能需要做表升级，在做表关联时用另外一个非自增主键ID做关联，或者使用全局自增ID或雪花算法统一获取全局主键ID。 阿里云的数据库暂时没有用过，多了解支持的一些功能，匹配下是否更适合自己的业务。
2019-08-152
