本文主要是介绍【架构师面试-存储-6】-MySQL分库分表的拆分规则，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1：单节点MySQL的瓶颈在哪

你是个天才，你浑身是铁，碾的了多少钉子

MySQL单机的存储能力、连接数是有限的，它自身就很容易会成为系统的瓶颈。

当单表数据量在百万以里时，我们还可以通过添加从库、优化索引提升性能。

数据量朝着千万以上趋势增长，再怎么优化数据库，很多操作性能仍下降严重。为了减少数据库的负担，提升数据库响应速度，缩短查询时间，这时候就需要进行 分库分表 。

2：什么是分库分表

分库分表就是要将大量数据分散到多个数据库中，使每个数据库中数据量小响应速度快，以此来提升数据库整体性能。核心理念就是对数据进行切分（ Sharding ），以及切分后如何对数据的快速定位与整合。

针对数据切分类型，大致可以分为：垂直（纵向）切分和水平（横向）切分两种。

3：垂直拆分：根据业务逻辑拆分

垂直分库：安装业务垂直拆分数据库

垂直分表

优点

业务间解耦，不同业务的数据进行独立的维护、监控、扩展

在高并发场景下，一定程度上缓解了数据库的压力

缺点

提升了开发的复杂度，由于业务的隔离性，很多表无法直接访问，必须通过接口方式聚合数据，

分布式事务管理难度增加

数据库还是存在单表数据量过大的问题，并未根本上解决，需要配合水平切分

4：水平拆分：根据sharding规则拆分

库内分表

库内分表虽然将表拆分，但子表都还是在同一个数据库实例中，只是解决了单一表数据量过

大的问题，并没有将拆分后的表分布到不同机器的库上，还在竞争同一个物理机的CPU、内存、网络IO。

分库分表

分库分表则是将切分出来的子表，分散到不同的数据库中，从而使得单个表的数据量变小，

达到分布式的效果。

优点

解决高并发时单库数据量过大的问题，提升系统稳定性和负载能力

业务系统改造的工作量不是很大

缺点

跨分片的事务一致性难以保证 

跨库的join关联查询性能较差

扩容的难度和维护量较大

5：有哪些sharding规则

hash取模

优点

数据分片相对比较均匀，不易出现某个库并发访问的问题

这样同一个用户的数据都会存在同一个库里，用 userId 作为条件查询就很好定位了

缺点

但这种算法存在一些问题，当某一台机器宕机，本应该落在该数据库的请求就无法得到正确的

处理，这时宕掉的实例会被踢出集群，此时算法变成hash(userId) mod N-1，用户信息可能

就不再在同一个库中。

扩展性较差

取值范围，举例：根据年代

优点

单表数据量是可控的

水平扩展简单只需增加节点即可，无需对其他分片的数据进行迁移

能快速定位要查询的数据在哪个库

缺点

由于连续分片可能存在数据热点，如果按时间字段分片，有些分片存储最近时间段内的数据，

可能会被频繁的读写，而有些分片存储的历史数据，则很少被查询。

如果您觉得文章好看，欢迎点赞收藏加关注，一连三击呀，感谢！！☺☻

这篇关于【架构师面试-存储-6】-MySQL分库分表的拆分规则的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！