互联网应用架构：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。
前言
现在网络的访问量激增，数据的量能也激增，在进行DB层面设计的时候，很多时候都要考虑分库分表，但是笔者发现一个问题，就是很多人一遇到这种问题就直接分库分表，不考虑现实的环境应该怎样？或者不考虑现在的项目应该怎么去设计，是否需要分库，是否需要分表。业务的增量如何？如何做到根据业务做后续拓展，今天我们来聊一下针对mysql的几种分库分表方案。
性能分析
俗话说，知己知彼，方能百战不殆。要想解决问题，那就必须知道我们的问题所在，及尽可能预测后面要发生的问题。在一个系统中，针对不同的业务，设计不同的方案，例如并发问题，例如存量问题，总结起来有以下三种问题。
1、网络IO问题
互联网的世界什么东西最常见，就是高并发，并发一高很多你见不到的问题就来了，其中请求的数据太多导致宽带不够，这就是网络IO问题。
2、磁盘IO问题
现在很多时候，我们在进行数据库查询的时候经常要做缓存，但是缓存也不能万能的，有时候热点数据很多，缓存已经放不下导致几乎全部走数据库查询，这样子在高并发请求下的每一次请求都会消耗大量的磁盘IO，从而查询速度会降低下来，现在的直接IO或者零拷贝也只能缓解，并不能最终解决问题。
3、计算性能问题
在普通的应用程序中一般都是CPU计算，虽然速度很快但是架不住大量的查询，例如单表数据很大，单表字段太多，没有合适的索引，SQL查询需要优化等，从而导致CPU的计算效率很低，导致CPU出现性能瓶颈。
针对以上三种问题，我们来讲讲不同的分库分表方案
分库分表不同实现
1、垂直分库
1.1.原理
按照业务定义不同，把不同的表放入到不同的库里面
1.2.切入点
以业务为导向，例如订单系统，库存系统
1.3.结果
每个数据库的业务范围不一样，因此每个库里面的表结构不一样
每个数据库里面的数据并不一样
1.4.场景
现在经常做的微服务系统，很多时候都是一个服务一个数据库
1.5.优点
面对一些高并发，高存量的时候，每个数据库都可以独立服务化存在，从而实现服务化的集群部署
1.6.缺点
由于把全量数据分散到各个数据库中去，在面对一些复杂的业务场景的时候会出现数据聚合问题，需要把各个数据库里面的数据聚合在一起，这需要根据不同的需求设计不同的实现方案。
2、垂直分表
2.1.原理
根据特定的业务场景寻找热点数据，并根据热点数据做表切分
2.2.切入点
主从表的设计思想
2.3.结果
存在实际意义的主从表之分，主表与从表之间一般采用主键进行数据关联
2.4.场景
这里主要应对一些复杂的业务场景，并发量不大但是计算比较大的情况，存在一定情况的数据冗余，查询数据的由于缓存数据的减少从而增加了磁盘的IO请求，例如缓存了主表的基础数据，但是从表需要查询。
2.5.优点
抽离出共性或者可以作为热点的数据，降低磁盘IO的瓶颈
2.6.缺点
由于一个表被拆分成两个，导致进行关联查询的时候容易增加CPU的计算负担，特别是在写SQL的时候采用join，是比较考验CPU的计算能力，因此针对这方面，笔者建议在代码层面进行数据的聚合。
3、水平分库
3.1.原理
按照一定的策略入hash或者range等，把数据分散放到不同的数据库上。
3.2.切入点
根据规则（技术算法层面或者业务规则）数据分散放到不同的数据库
3.3.结果
每个数据库结构一样，但是每个数据库的数据是不一样的
每个数据库并没有任何的交集，他们只存储部分数据
3.4.场景
数据量比较大，并发量比较小的时候
3.5.优点
数据分散来，从而来减少每个数据库的压力
3.6.缺点
当数据库多了的时候，在进行计算跟数据读取的时候，磁盘IO，网络IO，CPU计算都会成倍增长，这点上需要非常注意做适当操作，不可以随意切分。
4、水平分表
4.1.原理
按照一定的策略入hash或者range等，把数据分散放到不同的表上
4.2.切入点
以每个表的某些字段为切分点，例如订单日期等，每三个月一个表
4.3.结果
每个表的结构一样
每个表的数据不一样
4.4.场景
当某一个表增量比较大，可以按照指定的字段作为切分点来做，例如订单，例如历史记录都可以做
4.5.优点
查询特定业务范围的数据，表数据减少了从而增加来查询效率
4.6.缺点
分表后数据分散在不同的表中，联合查询会增加磁盘的IO以及CPU的计算，尽可能放弃join并在代码上实现数据聚合操作
分库分表中间件
Mycat
Sharding-sphere
选型原则：建议社区的热度优先，笔者以前用sharding-sphere，现在喜欢用mycat，文档及社区热度较好。
总结
不是所有的应用都适合分库分表或者需要分库分表，进行分库分表的时候代表着你引入了更加复杂的问题，是垂直还是水平，分几个库，分几个表都需要做增量预测，从而达到一个平衡态。
--END--
作者：@互联网应用架构
原创作品，抄袭必究
如需要源码或转发，请关注后私信我
部分图片或代码来源网络，如侵权请联系删除，谢谢！