如何解读数据库主键数据类型

如何解读数据库主键数据类型

深度分析MySQL数据结构

---

---

前言

一、“主键就是加了唯一性约束的聚集索引”？

在刚接触数据库时，我曾一度认为这是正确的，但很遗憾，随着对InnoDB 的了解，这并不是一个非常正确的
结论，现在我更认为 主键是一中约束，并且依赖于索引。

二、InnoDB 的索引模型

为什么不能用字符型做主键

结论非常简单：效率不行，数据量大的时候非常慢

为什么： InnoDB的索引模型非常有趣，数据结构使用了B+树，B+树的IO相较于二叉树有了明显的降低，对于查找数据有了更好的效率。而B+树的能高效执行的原因就是因为有序的索引。

很多朋友会问
在使用一个字符类型的数据作为索引查询时，速度就不如主键查询快吗
在使用一个字符类型的数据作为索引查询时，B+树还有他的作用吗
当然，主键查询，速度会更快，B+树同样也会起作用

如果有不懂B+树的朋友可以看一下图文并茂的另一篇文章
这里引用一下
https://blog.csdn.net/qq_26222859/article/details/80631121

InnoDB 的索引组织结构
执行主键索引查询时，会直接在左侧b+树中查到ID为300的内容 并获取R3，而如过使用k值做非主键索引查询，会在右侧b+树先找到k值为3的ID，内容为300，再执行一次回表操作，重新来到左侧b+树进行查询ID为300的内容，这就回到我们的主键索引查询执行的那一步。所以不论k为什么类型的变量，B+树都可以为其提供更快的效率。

那么在这里为什么业务字段不行，很简单，业务字段不容易保证有序插入，但自增的id却可以。同理，在有些业务场景下的分布式ID大小也是有有规律的，所以一样可以生效

三、如何选用主键的数据类型

在这里很多朋友应该都了解现在稍大的Sass系统都使用BingInt或者更大的数据类型，那我们如何选择最优的解决方案呢？
1.Int型数据类型，如果有符号为22亿，无符号42亿，如果我们的数据量达不到这个标准，完全可以使用IO较低的Int而非BigInt。那如果高于了这个量级，可以选用BigInt。
2。请不要忘记分布式ID的参与，在分布式场景中，我们经常会用分布式ID对某一个数据进行唯一的标识，也可以提升我们的安全性，但此时的消耗量相对较大，所以要记得平衡这个因素

四、索引可以全面提升效率吗

当然不行，索引只是提供了一个目录的功能，而且索引会降低增删的效率，原因也很简单，需要在两个树中同时进行改动。但实际场景中的大部分业务都是因为查询速度过低，所以才有了读写分离的概念。
因此我们可以做一定的权衡，如果非常特殊需要频繁操作的表，就不要添加索引。