我们在面试的时候经常会遇到分库分表分库的问题！今天给大家介绍一下互联网公司常用的MySQL分库分表方案！希望对你的面试有所帮助！图片来自Pexels数据库瓶颈，无论是IO瓶颈还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，逼近甚至达到数据库能够承载的活跃连接数的阈值.从业务服务的角度来看，很少或没有可用的数据库连接。那你可以想象一下（并发、吞吐量、崩溃）。第一类IO瓶颈：磁盘读IO瓶颈，热数据太多，数据库缓存放不下，每次查询都会产生大量IO，减慢查询速度→分库垂直分表。第二种：网络IO瓶颈，请求数据过多，网络带宽不足→分库。第一类CPU瓶颈：SQL问题，如SQL包含join、groupby、orderby、非索引字段条件查询等，增加CPU运算→SQL优化，建立合适的索引，在业务进行业务计算服务层。第二种：单表数据量过大，查询时扫描行过多，SQL效率低，最先出现CPU瓶颈→水平分表。分库分表横向分库横向分库，如下图：多个数据库。结果：各库结构相同，各库数据不同。没有交集。业务所有权来自垂直分库。分析：库多了，IO和CPU的压力自然成倍增加。Horizo??ntaltablesplitHorizo??ntaltablesplit，如下图所示：概念：以字段为基础，按照一定的策略（hash、range等），将一个表中的数据拆分到多个表中。结果：各表结构相同，各表数据不同。没有交集。所有表的union是全量数据场景：系统的绝对并发没有增加，但是单表数据量太大，影响了SQL。效率增加了CPU的负担，以至于成为瓶颈。分析：表数据量小，单条SQL执行效率高，自然减轻了CPU的负担。垂直分库垂直分库，如下图所示：概念：以表为基础，根据不同的业务隶属关系，将不同的表拆分到不同的库中。结果：每个库的结构不一样，每个库的数据也不一样，没有交集。分析：至此，基本可以面向服务了。比如随着业务的发展，公共配置表、字典表等越来越多，这时候可以把这些表拆分成一个单独的库，甚至可以面向服务。此外，随着业务的发展，已经孵化出了一套商业模式。这时候可以把相关的表拆成一个单独的库，甚至可以服务化。垂直分表垂直分表，如下图所示：概念：以字段为基础，根据字段的活跃程度，将表中的字段拆分成不同的表（主表和扩展表）。结果：每张表的结构不一样，每张表的数据也不一样。一般来说，每张表的字段至少有一个列交集，通常是主键，所有表的并集用来关联数据就是全数据场景。:系统的绝对并发没有增加。表中记录不多，但是字段很多，而且热数据和非热数据在一起，单行数据需要的存储空间比较大。导致数据库缓存中的数据行减少，查询时会读取磁盘数据产生大量随机读IO，造成IO瓶颈。分析：可以使用列表页和详情页来帮助理解。垂直分表的原理是将热点数据（可能冗余，经常一起查询的数据）放在一起作为主表，把非热点数据放在一起作为扩展表。这样可以缓存更多的热点数据，从而减少随机读IO。拆解后，如果要获取所有的数据，需要关联两个表来获取数据。但是切记，千万不要使用join，因为join不仅会增加CPU负担，还会将两个表耦合在一起（必须在一个数据库实例上）。对于关联数据，应该在业务服务层做文章，分别获取主表和扩展表的数据，然后使用关联字段将所有数据关联起来。分片工具常用的分片工具如下：sharding-sphere:jar，原名sharding-jdbc。TDDL：jar，淘宝分布式数据层。Mycat：中间件。......注：工具优劣请自行研究，官网和社区优先。分库分表步骤根据容量（当前容量和增长量）评估分库或分表的数量→选择key（偶数）→分表规则（hash或range等）→执行（一般是doublewrite）→扩展问题（尽量减少数据移动）。分库分表问题非分区键查询基于水平分库分表，分库策略是常用的hash方式。①除了分区键，终端上只有一个非分区键作为条件查询。映射方式，如下图：遗传方式，如下图：注：写的时候，遗传方式生成user_id，如图。至于xbit基因，比如需要分8个表，23=8，所以x取3，也就是3bit基因。基于user_id查询时，直接取model路由到对应的分库或分表即可。基于user_name查询时，首先通过user_name_code生成函数生成user_name_code，然后建模路由到对应的分库或分表。id由常用的Snowflake算法生成。②除了尾部的partitionkey外，使用多个非partitionkey作为条件查询映射方式，如下图：冗余方式，如下图：注意：查询时根据order_id或buyer_id，路由到db_o_buyer库，根据seller_id查询时，路由到db_o_seller库。感觉有点本末倒置！还有什么好的方法吗？改变技术栈怎么样？③除了分区键，后台还有各种非分区键组合条件查询NoSQL方式，如下图：冗余方式，如下图：非分区键跨库跨表分页查询问题是基于水平数据库和表的分区，拆分策略是常??用的哈希方法。注：用NoSQL方法（ES等）解决。扩容问题基于水平分库分表，拆分策略是常??用的hash方法。①库的水平扩展（从库方法升级）注：扩展一倍。②水平扩展表（双写迁移方式）步骤如下：第一步：（同步双写）修改应用配置和代码，添加双写，部署。第二步：（同步双写）将旧库中的旧数据复制到新库中。第三步：（同步双写）在旧库的基础上校对新库中的旧数据。第四步：（同步双写）修改应用配置和代码，去除双写，部署。注意：双重写入是一种常见的解决方案。分库分表总结分库分表总结如下：分库分表，首先要知道瓶颈在哪里，然后合理拆分（分库分表）-分库还是分表？横向还是纵向？有多少？）。分库分表不能拆分。键的选择很重要，不仅要考虑偶数拆分，还要考虑非分区键查询。只要能满足要求，拆分规则越简单越好。作者：尜尜人物编辑：陶佳龙来源：cnblogs.com/littlecharacter/p/9342129.html
