day02/上午/025-尚硅谷-尚融宝-id策略的问题分析

好说一下刚才嗯，下课的时候咱们同学提的问题，比如说咱们这边有三个数据库啊，我这怎么创建呢？这样写吧。外框线。然后呢，这就是。一个两个。三个是吧，啊三个数据库，三个数据库里面呢，我们存数据，比如说这个里面呢，我们就规定1234567。嗯，一二三四五六七八九十吧，要不然我这数学不太好，我怕我算不明白。好这样这样啊，一二三四五六七八九十。每个这个数据库表里面有十条记录对吧，十条记录的话呢，比如说这存一二。然后呢？三四五六七八九十好，那这样的话呢，这个数据库表里面呢，也存十角记录，他从几开始存呀，像刚才我们说的那个其中一种方案，他从十一开始存，然后这是12对吧？啊，然后1234存到20对吧，然后如果扩展的话，有的同学就想了方法了。

有的同学就想了方法了。什么方法呢？就是在。我把它弄好一点儿啊。什么方法呢，就是在这个数据库里呢，我就查询，但是第三个数据库了，那么按规范的话，我一定是从二十一开始。对吧，那如果未来我要扩展第四个数据库的话，这又扩展了一个数据库。那如果按规范的话，我应该从。30亿开始。是这个意思吧，嗯，好，然后接下来呢。我们来看。有没有问题，肯定是有问题的呀，因为假设说我们这面呢，是逐渐自增长啊，就是逐渐自增长，那逐渐自增长的话，你能够保证这个地方一定是到十结束吗。

不能够保证，因为比如说你增加了一条记录，在增加第二条记录的时候，第二条记录这个ID为二的这个用户被你删掉了，那这个时候呢，你ID为3456789的用户可能就上移了，是这意思吧？啊好，上移了之后，那这是不是不够十条记录了。不够十条记录了的话，那你再往这里面填记录的时候，你是不是就就得是11了，你如果这个是11的话，那你这个数据库表，你是不是就，嗯。和这个11就冲突了，那有的同学说，那我不填删了就删了，那好假设说我们就这样的一个规范，这个填完了之后呢，这个是11，然后十二十三这面删了就删了，那删了就删了，只要我新增我就往后加，只要我新增我就往后加，随着时间的流逝，可能前面的这个用户啊，他由于一些某种原因呀，或者是由于一些数据呀，啊，比如说这个不是用户数据，是一个日志。啊，日志的话，一般情况下我们会有一年之前的日志就删掉了，那么这个可能里面有大部分数据就被删掉了，一删的话，你看看是不是又会出现这种数据不平衡的现象，就是他的数据过少，他的数据特别多，他新加的数据也特别少，对吧？所以这个是逐渐增增的一个问题，还有一个呢，就是跟刚才咱们说的那个另外一种解决方案啊，大家可能也有一个问题，什么问题呢？

就这样的一个问题，我再重写一下吧。啊，这种解决方案呢，是这样的，就是我们呢，也是是这样定义的。好，这个呢是一对吧，然后这个呢是二。然后这个呢是三。然后呢，这个呢是四啊，这个呢是五，然后这个呢是六对吧，好然后呃。以此类推啊，我看看他会不会给我加七。加上了哈，好这样的话呢，以此类推，以此类推的话呢，这个最大的值应该是28，好，那么这面的最大的值应该是几啊。

29，然后这面最大的值应该是几啊？30对吧，好，那有同学说，那我最新的这个数据库表，我不就定义成41不就完了吗？这很简单呀，对吧，那嗯，你我就定义最大的值嘛，定义成41。那么还是和刚才的问题是一样的，这个数据库表你最大值定义成41的话，那未来假设说啊，这个数据库表之前这个四呢，这条记录呢，曾经被删掉了。就是当后面这些表都没有的时候，这个四之前就被删掉了，这个四被删掉了之后呢，然后呢，很显然我这个后面的这个数，我就要由谁来填充啊。我要由。三十一来填充，这才能凑够十个数对吧，才能填满这张表，然后呢，31之后啊，这面呢，就是也是二二十九。

我看一下啊，这是31。41会和谁冲突啊？41我想一下啊，41会和会和这里面冲突，然后这里面的数据假设说我再删，就是之前也删过，删过之后呢，然后我再往下去。扩展。应该是几。三十二十二，二十五四十七，那这面会有41对吧。我看一下啊啊对，这面会有41号，那这面的前面的记录曾经我删过。好删完了之后，假设说12345689，假设说这是十条记录啊，那么这个之前呢，他已经把41就占用了。是这意思吧，那这个时候你呢，硬性的就规定我这个表从四十一开始，是不是和这个表里的41。冲突了。明白这个意思吧，那有同学又说了，那我从这个表里面找最大值，我发现呢，这个表里的最大值是40，这个表里最大值是41，这个表里最大值是30，那我从42开始。

那你有没有可能说我我我这个表未来我能扩展到42呀。我未来扩展扩展扩展，我我我有可能就加到42了，对吧，因为我目前为止，我这个表里面，我可能不够十条记录。对吧，我不够时效记录的话，那我未来再扩展扩展，我有可能在某一天，诶，我就扩展到42了。我又把记录又删了一点儿。遨游扩展。又扩展。扩展。又又又到42了，那是不是又跟他冲突了，所以你无论采用哪种方式啊，它实际上呢，都是不安全的，都是不安全的，因为我们不可能规定说这一个表一定是按顺序走的，他有可能中间是有这个ID的缺失的，有ID缺失了后面就补上了，你后面一补的话，你这面的起始值你就没法设置。

明白这个意思吧，啊，然后有同学说呢，就是所有的表添加之前先查询一下，先查询一下也会有一个问题，就是我在添加之前，我先把所有的表查询一下，然后我再往里添。首先第一个问题，性能问题。对吧，你每次往新表里面，你你添加一个新记录的时候，你都要把之前的这个数据库里面你都查一下，那这个第一个是性能的问题啊，当然了，这个性能问题可能就是我创建一个新的数据库的时候，可能才会影响，但是还有一个问题，还有一个问题是什么，比如说现在就到45了，我从46开始。我从46开始的话，那么未来这个46往后的这个数据可能就被后面的这些表占据了，然后我就这样填，那因为我是这样就是这样横着就是123，然后46，然后就这样填的嘛，对吧？好填完了之后呢，有没有可能说。

我在这个数据库当中，我把这个表。删掉了，删掉了之后，那你说我这些数据库表，我以后再不添加新的记录了吗。我如果这个数据库表我添加新的记录的话，是不是又跟他冲突了，为什么有同学说这已经满了，要添进去了呀，添进去了他有可能随着时间的流逝，就有些数据没用的，他可以删掉啊。对吧，有些数据没用的，删掉了这个数据库是不是就有余位了，有余位了的话，新数据是不是就可以进来了，新数据进来的时候是不是就有可能和这个。数据库表的这个数据冲突。明白这个意思吗？啊，所以说第一个问题就是效率低，第二个问题就是什么呀，还是有可能会冲突的。就是你不和人家冲突，人家可能和你冲突。所以说它总是会面临这样的问题的。然后。明白吧，嗯，好，所以呢。

这样的方案呢，它是有瓶颈的，它是有瓶颈的，那用咱们同学的方式呢，其实是可以解决这个问题的，但是他这个解决问题的方法并不优雅。对不对，很麻烦的啊，很麻烦的这样的一些方法，而且一定会在未来，当你的这个系统规模越来越大的时候，你这个数据库表里面的数据啊，就完全没有任何规律了，就乱套了一锅粥了。是不是呀啊，我们就没有办法去对它进行优化了。是不是啊，所以大家课后的时候再好好想一想啊，你看刚才我写的时候就一会加针一会加这就就已经乱了，实际上啊，所以这个并不是一个非常高效的解决方案啊，那所以呢。有问题的同学，课后再好好思考一下，看一看你的那个方案会不会被你自己所想的一些悖论是吧，给推翻了，是能够推翻的，好，那所以呢，我们还有一些其他的解决方案，还有其他的解决方案呢，就哈希了。

哈希是什么？哈希就是随意生成一个随机数。对吧，数据和数据之间，因为有了哈希这样的一个概念的一个存在，它是没有关系的，呃，什么叫哈希？其实就是我们用一系列的算法，然后呢，就随机的生成一个和其他的ID都不一样的数据，然后如果他不一样的话，你是不是往哪个数据库表里插就行了，就保证ID唯一性就可以了嘛，对不对，嗯，好，但是哈希有一个。问题。这个问题呢，就是。嗯。表的这个，呃，就是我说我刚才说的那个随机数的那个哈希啊，啊刚这个这个哈希是什么？这个哈希是刚才我们讲的那那种方式，就是这个课件里面的这个哈希啊，是讲的刚才我们所说的那个取模运算的那种方式，就是每个表都有，也是呃这个147，然后那个258这种方式啊，曲模运算的这种方式，这是课件里的哈希，然后再说一下广义的哈希，广义的哈希是什么？就是一个随机数。

正常情况下，在我们啊应用程序当中，我们所说的哈希就是一个地址，对吧？啊，对于任何一个数据来说，他在内存当中的地址应该是唯一的，对不对啊，所以说呢，对于我们广义上的哈希来说呢，针对一个数据，那么我们用哈希算法给他算出来一个值，那么这个值呢，应该是一个唯一值啊好，那这个唯一值呢，我们有各种各样的算法去给他算，第一种算法呢，就是比如说UUID。UUID呢，就是生成一个随机数啊，生成一个随机数呢，然后就付给这样的一个，呃，一个数据就可以了，那如果呢，我们想结合哈希它原本的意思呢，那你就把这个这个数在这个内存当中所存储的地址再拿出来，和我们生成的这些随机数啊，或者是其他的一些计算因子呀，加起来参与运算啊，总之算出来一个和其他的都不一样的就行啊好。

那么这个的问题是什么呢？就是。它没有连续性。没有连续性啊，什么叫没有连续性呢？你的idea啊。他在增加到数据库当中的时候呀，他没有先后顺序，比如说在一个数据库表当中，我的这个哈希有可能是345，然后下一条呢，就有可能是123，再下一条呢，有可能是789，再下一条呢，有可能是456，啊是这样的，它是没有连续性的，再有呢，就是哈希有的时候呢，比如说用UUID生成的哈希呢，它并不是一个字符串，它并不是一个数字的形式，它是字符串的形式。就类似于。这样的一个。啊，字符串的形式啊。是吧，那就长这个样子的好，这些都有什么问题呢？就是作为ID的话，作为ID的话，如果作为主件的话，它不能和我们数据库MYSQL当中的句促索引一起用。

不能和句促索引一起用。什么叫句促索引呢？你们的那个my circle高级的课程当中会学到这部分的内容，就是如果这个值是我们数据库中的主键。那么。这个值最好是有先后顺序的，如果它是有先后顺序的话，那就说明它是一个句促索引，那么在查询的时候会最大程度的提高它的查询效率。啊好，这个大家课下的时候去了解一下居速索引，或者是你们学完这个买SQL高级的时候，你根据那个居速索引，你再详细的去了解它，因为这是买搜狗高级里面的内容我就不深入了啊，总之结论是什么？结论是如果这个值是我们的主见的话。是主见的话啊。一般情况下，ID是我们的主见。那么它。最好的一个设计方案是有先后顺序的。

这样的话能够帮助我们在根据组件的查询数据库数据的这种需求的前提下，最大的提高查询效率啊，或者是说我在用一个最直白的话来跟大家讲，就是ID，如果有顺序。查询效率高啊。ID如果没顺序。查询效率低。明白吧，啊，再说一遍ID，如果有顺序。我们查询效率高，ID如果没顺序我们查询效率低，那这个具体原因是什么？大家在学买搜狗L高级的时候，你结合句术索引去理解好，那么如果是这样的一个结论摆在你面前的话，那你就发会发现如果通过UUID。这种方式，或者说通过随机的一个哈希算法生成的这样的一个随机数的这种方式来生成我们的ID的话呢，它就不利于我们数据库的一个查询优化啊，所以说呢，虽然呢，它能够解决我们之前所面临的这种组件自增啊，还有那个取模算法呀，这样出现的一些问题，但是呢，他又有新的问题了啊，所以说有没有一个可以解决以上所有问题的一个主键生成策略吗？那么肯定是有的呀，要不然咱们就没有这堂课了，那就是学画算法了。

好，那接下来呢，我们就来说一下这个雪花算法。