主要介绍MySQL常用的子数据库和子表的方案汇总，通过实例代码介绍的非常详细，有一定的参考价值，感兴趣的朋友可以参考一下。
目录
一、数据库瓶颈二。子数据库表2。水平表3。垂直表4。垂直表3。子数据库表工具四。子数据库表步骤五.子数据库表问题
1.非分区键查询问题2。非分区键跨数据库跨表分页查询问题3。产能扩张问题6。子数据库和子表汇总。
一、数据库瓶颈
无论是IO瓶颈还是CPU瓶颈，最终都会导致数据库的活动连接数增加，进而接近甚至达到数据库所能承载的活动连接数的阈值。从业务服务的角度来看，几乎没有可用的数据库连接。然后就可以想象了(并发、吞吐量、崩溃)。
1.IO瓶颈
第一个是磁盘读IO的瓶颈。热数据太多，数据库缓存容纳不下。每次查询都会产生大量的IO，降低了查询速度——子数据库和垂直子表。
第二种：网络IO瓶颈，请求数据太多，网络带宽不足——子数据库。
2.CPU瓶颈
第一种：SQL问题，比如SQL包括join、group by、order by、非索引字段条件查询等。增加CPU操作-SQL优化，建立合适的索引，在业务服务层进行业务计算。
第二种：单个表的数据量太大，查询时扫描的行数太多，SQL效率低，CPU率先出现瓶颈——水平表拆分。
二、分库分表
1、图书馆的水平
概念：基于字段，按照一定的策略(hash，range等。)，将一个库中的数据拆分到多个库中。
结果：
每个库的结构都是一样的；
每个库的数据不一样，没有交集；
所有库的并集是全数据；
场景：系统的绝对并发上来了，很难从根本上解决分表的问题，也没有明显的业务归属来垂直划分数据库。
10-59000库多了，io和cpu的压力自然可以成倍降低。
2、水平分表
分析：根据字段并按照一定的策略(hash、range等)将一个表中的数据拆分成多个表。).
概念：
每个表的结构是相同的；
各表数据不一样，没有交集；
所有表的并集是完整数据；
结果：系统的绝对并发没有上来，但是单个表的数据太多，影响了SQL的效率，增加了CPU的负担，以至于成为瓶颈。推荐：SQL查询优化原理分析
场景：表数据少，单个SQL执行效率高，自然减轻了CPU的负担。
3、垂直分库
分析：以表为基础，不同的表按照不同的业务归属拆分成不同的库。
概念：
每个库的结构都不一样；
每个库的数据也不一样，没有交集；
所有库的并集是全数据；
结果：系统的绝对并发上来了，可以抽象出一个独立的业务模块。
场景：到这个点，基本可以上菜了。
比如随着业务的发展，常见的配置表、字典表等越来越多。此时，这些表可以被分离到单独的库中，甚至可以被服务。再者，随着业务的发展，已经孵化出一套商业模式。此时，相关的表可以被分离到单独的库中，甚至可以被服务。
4、垂直分表
分析：根据字段的活跃度，将表中的字段分成不同的表(主表和扩展表)。
概念：
每个表的结构都不一样；
每个表的数据也不一样。一般来说，每个表的字段至少有一个列交集，通常是主键，用来关联数据；
所有表的并集是完整数据；
结果：系统的绝对并发没有上来，表中记录不多，但是字段很多，热数据和非热数据在一起，单排数据需要的存储空间大。这样一来，数据库中缓存的数据行数减少，查询时会读取磁盘数据，产生大量随机读取IO，造成IO瓶颈。
场景：您可以使用列表页面和详细信息页面来帮助您了解。拆分垂直表的原理是将热数据(可能是冗余的，经常一起查询)放在一起作为主表，非热数据放在一起作为扩展表。这样，可以缓存更多的热数据，从而减少随机读取IO。拆解之后，如果想要得到所有的数据，就需要关联两个表来得到数据。
但是记住，千万不要用join，因为join不仅会增加CPU负担，还会说两个表耦合在一起(必须在一个数据库实例中)。关联数据，要在业务服务层做文章，分别获取主表数据和扩展表数据，然后用关联字段关联，获取所有数据。
三、分库分表工具
Harding-sphere: jar，原名sharding-JDBC；
TDDL:jar，淘宝分发数据层；
Mycat:中间件。
注意：请自行研究工具的优缺点，官网和社区优先。
四、分库分表步骤
根据容量评估子数据库或子表的数量(当前容量和增长)-选择键(偶数)-子表规则(hash或range等。)-执行(一般是双写)-容量扩展(尽量减少数据移动)。
第五，分库分表的问题。
1、非partition key的查询问题
基于横向的数据库划分和表划分，拆分策略是常见的哈希方法。
分析：
映射方法
基因方法
注意：写的时候user_id是用遗传方法生成的，如图。比如xbit基因，有8个表，23=8，那么x取3，也就是3位基因。根据user_id查询时，可以直接取模块，路由到对应的子数据库或子表。
根据用户名查询时，用户名代码由用户名代码生成函数生成，然后模块化路由到对应的子数据库或子表。按id生成常用雪花算法。
端上除了partition key只有一个非partition key作为条件查询
映射方法
冗余方法
注意：按order_id或buyer_id查询时，路由到db_o_buyer库，按seller_id查询时，路由到db_o_seller库。感觉是本末倒置！还有其他好办法吗？改变技术堆栈怎么样？
端上除了partition key不止一个非partition key作为条件查询
NoSQL方法
冗余方法
2、非partition key跨库跨表分页查询问题
基于横向的数据库划分和表划分，拆分策略是常见的哈希方法。
注：NoSQL方法用于解决问题(ES等)。).
3、扩容问题
基于横向的数据库划分和表划分，拆分策略是常见的哈希方法。
后台除了partition key还有各种非partition key组合条件查询
水平扩容库（升级从库法）
注意：膨胀是双倍的。
水平扩容表（双写迁移法）
第一步：(同步双写)修改应用配置和代码，加上双写和部署；
第二步：(同步双写)将旧数据库中的旧数据复制到新数据库中；
第三步：(同步双写)根据旧数据库校对新数据库中的旧数据；
第四步：(同步双写)修改应用配置和代码，去掉双写，部署；
注意：双写是通用方案。
六、分库分表总结
要划分数据库和表，首先要知道瓶颈在哪里，然后才能合理拆分(划分数据库还是表？横的还是竖的？多少？)。并且不能为了子数据库和子表的目的而拆分。
考虑到均匀分割和非分区键查询，选择键非常重要。
只要能满足需求，拆分规则越简单越好。
关于MySQL常用子数据库和子表方案的总结这篇文章到此为止。有关MySQL子数据库和子表的更多信息，请搜索我们以前的文章或继续浏览下面的相关文章。希望大家以后能多多支持我们！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。