day02/上午/023-尚硅谷-尚融宝-垂直分表和水平分表

好，那接下来呢，我们来看一下啊，实际上呢，如果细心的同学啊，我们在昨天写程序的时候呢，就可能就会一直有一个疑问，就是为什么我们生成的ID是长这个样子的。对不对啊，这个ID呢，看起来好像挺高大上的样子哈，就是为什么啊，因为它长啊，对不对啊，他比我们这个字就是这123要长很多，然后呢，也不知道是一个什么规律，貌似是有顺序的，你看这13568。对吧，然后135687，这是686，貌似是有顺序的，貌似是有规律的，貌似是从小到大的，但是貌似还是好像挺随机的这么一个数，因为你看前面。他就是把顺序体现出来了，但是你你又看后面他好像又有一些随机性，对不对，这是什么呢？这个叫做呃。用雪花算法生成的分布式ID啊好，分布式这个单词一出来的话，大家就觉得，哎呀好像挺厉害的，所以呢，我们现在呢，先来研究一下这样的一个概念，叫做雪花算法产生的这样的一个背景，或者是分布式ID产生的这样的一个背景，那我们未来在嗯，企业当中去写应用程序的时候呢，呃，十有八九呢，会遇到那种互联网项目，互联网项目的特点是什么呀，高并发。

对吧，用户特别多高访问量啊，所以呢，为了解决这个问题呢，我们就需要进行数据库的分库呀，分表啊，主从复制呀啊这样的一个操作啊，那这样的话呢，唯一的目的呢，就是呃，提高我们数据库的承载能力啊，让我们的数据库呢，可以接受更大的并发访问。可以存储更多的数据，好，那我们来看一下具体的数据库分表的方式啊，数据库分表呢，在企业当中呢，我们有两种方式，当然了，除了分表之外呢，实际上还有分库，对不对？分库呢，我们是在买SQL高级当中学的是吧？好那么所以我就不去详细的讲了，我呢就呃结合着我们雪花算法的背景啊，来详细的说一下数据库分表的情况，那么数据库分表呢，我们有两种这个分表的形式，一种呢是水平分表啊，一种呢是垂直分表，我们这个水平和垂直呢，是针对于表来说的，好那么水平分表和垂直分表都会应用于什么样的一个场景呢？我先来说一下数据库的垂直分表。

的这么一个情况啊。比如说你呢，就是。就去一个那个。婚恋网站啊，去一个婚恋网站的话，你不是你你去过吗？你们是不是有去过的呀，你去的时候你不是查询吗？查询的话你你怎么查，你肯定是对他那个性别有要求，对不对，不可能说你对性别没有要求，是男的女的都行是吧，所以你肯定会针对性别来查啊，然后呢，还有同学呢，可能会针对什么来查，针对年龄来查，你不可能什么年龄段都可以，对不对，所以呢，有同学会针对年龄来查，比如说20以下的呀，或者是什么60以上的呀，对不对，好这样去查。

呃，然后呢，查完了，那你就会发现你在这个使用这个，呃，这个系统的时候，你在查询的过程当中，你可能呢，就想查一下他的姓名，就想查一下他的年龄，对吧？啊有这样的一个需求啊好，然后查完了之后，具体他昵称什么，他的详细描述是什么，他的自我介绍是什么，是不是你在详细看他的个人资料的时候，然后。再进行一个展示和一个这个查查阅就行了，对吧？啊，这是一种需求啊，这是一种需求，记住啊，还有一种在我们，呃，就是互联网项目当中常见的一个需求是什么呢？就是。比如说像抖音呀，像这个。呃，微信呀啊，像这个QQ呀，像这个淘宝呀，它的用户量呢，都比较大，它的用户量大到什么程度呢？可能几百万几千万呢，嗯，是不够用的，那基本上都是几亿，十几亿，几十亿这样的一个规模，对不对啊，所以说呢，这也是一种需求，这叫什么需求啊，这个其实是针对于我们用户来说啊，并不是一个主动的需求，针对于系统来说呢，它实际上是一种被动的需求，就是并不是明确的能够写在这个需求文档当中的需求，而是呢，随着业务的规模的不断的扩大，这个是，呃，就是自然而然会产生的一种被动的需求，对吧，叫做数据访问量的一个需求，好，那么基于这两种需求，大家想，如果你想对数据库做扩展的话，你要怎么扩展？

如果你想对数据库扩展的话，你要怎么扩展，我们先来说这个第一种啊，第一种的话呢，一般情况下我们会采用。

垂直分表的形式，什么叫做垂直分表呢？比如说刚才我们提到啊，如果我们的这个数据库的这个内容啊，当然了你相对也会比较多，然后呢，你列也比较多，你查询量比较大的时候，这个时候呢，我们通常情况下会呢，把经常被查询的字段和数据量比较大的字段。给他拆分到不同的表当中。啊，比如说刚才我们说到的这个。Age和sex，它呢是主要用于查询的，而刚才我们提到的另外两个字段，Nickname昵称和description这个个人信息的一个描述，主要呢是用于你查完了之后他展示的，所以呢，后面的这两个展示字段啊，它一般不会在业务查询当中用到，而这个description这个字段叫做个人信息的描述，本身有可能又会比较长，对吧？因为一般情况下，你个人信息描述可能十几20个字是不够用的，少则几百个字，多则几千字，或者比较变态的几万字啊，好，那么这样的话呢，我们就可以将这样两个字段呢，独立到另外一张表中。

那么独立到另外一张表中之后呢，我们在查询的时候就可以对性能的提升做一个非常好的优化。明白哈，好，所以这个呢，其实隐含了一个数据库优化的一个方案，怎么样去优化你的数据库查询，就是把大字段。或者是把查询一般用不到的字段，我们把它分离到另一张表当中，所以呢，比如说这个。

我们就叫user表。啊，比如说我们有一个表叫user表，还有一个表我们就叫user info表，叫user的详细信息表，然后这两个表呢，我们可以用什么来做关联呀，比如说用ID做关联主，因为这两张表肯定是一对一的关系，对吧？啊如果是一对一的关系的话呢，我们直接主键关联就行了，那么user的ID。和user in for的ID，我们完全可以采用同样的一个值，那么user是有ID策略的，比如说逐渐自增长是user的ID策略，那么user in for，你就可以不给他设置ID策略，那么他的策略是什么呢？他的策略就是user是啥，我是啥。明白吧，啊，这个时候呢，注意啊，User in four，他有自己的策略，还有那个user他有自己的策略，User in four他就没有自己的策略了，他的策略就是user是啥，我是啥，这个叫主见一对一关联啊，主见。

一对一。关联明白吧，啊好，那这个呢，也是我们所说的垂直。垂。尺为垂，垂直。分表的一个具体的使用的一个方案，当然了这个前提呢，是本身这张表的数据量啊，也比较大的情况啊，你说我这个数据库表就100个用户，那你就没必要做拆分了，还不够麻烦的呢，你到时候一查询的时候还得做个关联查询，更影响性能是不是啊就。就嗯，没有达到目的，反而呢就本末倒置了，那就更因为你关联查询肯定比单表查询要影响性能，这个是一定的啊，那我们给他做分离的一个前提呢，是本身这个数据库表的这个数据量是非常大的，然后呢，而且还有这样的一个需求，那所以呢，我们就可以给他做一个垂直分表啊，所以刚才我说的呢，是垂直分表的一个情况，接下来呢，我们说第二种情况。

水平分表，水平分表呢，适用于前面我提到的用户量特别大的情况，什么叫特别大？就是超千万级别了。超千万级别了，有的时候呢，我们如果作为架构师的话，你就要警觉起来了啊，因为这个千万级别的数据呢，很有可能就是我们整个应用程序架构的性能瓶颈了，它会存在很多隐患的，所以呢，我们要考虑对它进行分表，呃，有的时候呢，这个数据库呀。他这个字段呀，并没有说这样的一些特性哈，就是没有说一些非常大的字段需要拆分出去，或者说没有说查询呀，然后展示啊，这样的一个，呃，这样的一个很明确的这样的一个垂直分表的这么一个方案的时候呢，而且数据量还特别大的时候呢，我们就要考虑水平分表了，那么水平分表的一个最主要的原则呢，就是第1000万级别以上你要考虑，但是并不一定说一旦达到千万我就一定要分，你还要考虑什么问题呢，就是。

你的这个表是不是并发量很大，如果你这个表是并发量超级大的表的话，那么到千万级别的时候我们就要分了啊，你这个表呢，单纯就是一个存数据的，比如说就是一个日志表。对吧，然后一般情况下也没人去查，就管理员没事看一看，看看有没有什么问题，那么你这个时候就没有必要千万级别就分，有可能你5000万再分一下，或者是1亿再分一下就行了，但是如果你这个表，比如说是个商品表，是个用户表，它的访问量特别大的时候，那你这个时候考虑千万级别你就要分了，有的时候你500万你可能要分了，就并发非常大的时候，你可能500万就要分一下，明白吧，所以这个呢，它并不是一个固定的数字啊，一定要根据我们的应用程序的一个实际的一个情况呢，进行灵活的配置，那另外还有什么呢？就是还有服务器方面的原因，比如说你服务器性能好。你能够承载这么大的并发，那么你呢，就可以五千万一分，一亿一分，但是你们公司的这个租用的服务器，或者是自己购置的这个服务器性能不是特别好，是吧？那你你就要干嘛呀，你就要分多一点，你分多一点的话，那你看你服务器的性能不太好，你本来图便宜，结果呢，你这不行啊，你还得分出去一个，分出去一个你还得再买一台服务器，明白吧，所以呢，那反而就浪费钱了，那我们可以用单一的服务器的价格呢，给他提升性能，然后买一个性能更好的服务器，这样啊，所以说这个过程当中，他没有唯一的一个，一定要怎么分，一定是几台服务器，一定是多少数据，这样的一个标准，一定是灵活配置的啊，好，所以这块是水平分表，所以呢，刚才我们说到了。

垂直分表在什么场景下使用，水平分表在什么场景下使用啊，绝大部分情况下呢，如果数据量特别大的话，首先我们要考虑的就是水平分表了，好有的时候呢，我们可以水平分表和垂直分表综合起来使用，你既水平分，业务垂直分，那这个时候我们的业务结构呢，就非常复杂了，好那我们刚才提到了业务结构的复杂性，业务结构的复杂性主要体现在哪个方面呢？水平分表。

垂直分表比较简单，垂直分表顶多我们回头做一个一对一的关联查询就可以了，但是水平分表问题就比较大，所以接下来呢，我们来说一下水平分表它所面临的业务复杂度啊。