Mysql二之数据库主键为什么不推荐使用UUID

深藏阁楼爱情的钟 2022-11-21 01:16 170阅读 0赞

### 数据库存储引擎 ###

通过上篇[Mysql一之索引概述][Mysql]我们大概对数据索引有了一定的了解，但是再说mysql索引之前不知各位对存储引擎是否了解。数据库存储引擎是数据库底层软件组件，数据库管理系统使用数据引擎进行创建、查询、更新和删除数据操作。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎还可以获得特定的功能。现在许多数据库管理系统都支持多种不同的存储引擎。MySQL 的核心就是存储引擎。

### 存储引擎分类 ###

MySQL支持多个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：

*  MyISAM存储引擎提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它也是5.5.5之前默认的存储引擎。
 *  MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎不支持事务处理，这两个引擎也都被默认包含在MySQL中。MEMORY存储引擎正式地被确定为HEAP引擎。
 *  InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所 有MySQL 5.1二进制分发版里，5.5.5版本之后InnoDB作为Mysql的默认存储引擎。
 *  EXAMPLE存储引擎是一个“存根”引擎，它不做什么。你可以用这个引擎创建表，但没有数据被存储于其中或从其中检索。这个引擎的目的是提供服务，在MySQL源代码中的一个例子，它存在的作用就是演示说明如何开始编写新存储引擎，为存储引擎开发的人员提供了方向。
 *  NDB Cluster存储引擎是被MySQL Cluster用来实现分割到多台计算机上的表的存储引擎。它在MySQL-Max 5.1二进制分发版里提供。这个存储引擎当前只被Linux, Solaris, 和Mac OS X 支持。
 *  ARCHIVE存储引擎被用来无索引地，非常小地覆盖存储的大量数据。
 *  CSV存储引擎把数据以逗号分隔的格式存储在文本文件中。
 *  BLACKHOLE存储引擎接受但不存储数据，并且检索总是返回一个空集。
 *  FEDERATED存储引擎把数据存在远程数据库中。在MySQL 5.1中，它只和MySQL一起工作，使用MySQL C Client API。

**常用存储引擎对比**

*  InnoDB 支持事务，支持行级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
 *  MyISAM 不支持事务，支持表级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
 *  Memory 不支持事务，支持表级别锁定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；
 *  NDB 支持事务，支持行级别锁定，支持 Hash 索引，不支持 B-tree、Full-text 等索引；
 *  Archive 不支持事务，支持表级别锁定，不支持 B-tree、Hash、Full-text 等索引；

InnoDB存储引擎作为事务型数据库的首选引擎，支持事务安全表（ACID），支持行锁定和外键，它也是我们创建数据库表的首选。![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70][]

上面也说了InnoDB存储引擎支持多种索引种类，但是InnoDB默认使用是B+TREE，为什么不使用BTREE，二叉树等下面对比下这几种数据结构：

1. 全表索引顺序查询：查询算法-复杂度O(n），大数据量基本靠等；

2. 二叉树查找（binary tree search）: O(log2n)；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 1][]

我们查询就是通过算法快速查询到col2存储的数据，为了能够快速的查询Col2的数据，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log2n)O(log2n)的复杂度内获取到相应数据。

3. hash索引 无法满足范围查找；

4. 二叉树、红黑树 \[复杂度O(h)\]因为二叉树/红黑树会导致树高度非常高，下图以红黑树为例(二叉树高度更高)，**平衡二叉树：**一个节点只能有左子树和右子树),逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，IO次数多查找慢,效率低。todo 逻辑上相邻节点没法直接通过顺序指针关联，可能需要迭代回到上层节点重复向下遍历找到对应节点，效率低；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 2][]

5. B-Tree: 每个节点都是一个二元数组: \[key, data\]，所有节点都可以存储数据。key为索引key,data为除key之外的数据。查询过程：从根节点进行二分查找，如果get则返回对应node的data，否则在相应区间的指针指向的nodes进行递归查找，直到get到或未找到节点返回null。  
缺点：1.插入删除新的数据记录会破坏B-Tree的性质，因此在插入删除时，需要对树进行一个分裂、合并、转移等操作以保持B-Tree性质。造成IO操作频繁。2.区间查找可能需要返回上层节点重复遍历，IO操作繁琐。

![20201030144032376.png][]

5. B+Tree: B-Tree的变异，与B-Tree相比，B+Tree有以下不同点：①非叶子节点不存储data，只存储索引key；②只有叶子节点才存储data。Mysql中B+Tree：在经典B+Tree的基础上进行了优化，增加了顺序访问指针。在B+Tree的每个叶子节点增加一个指向相邻叶子节点的指针，就形成了带有顺序访问指针的B+Tree。这样就提高了区间访问性能：如果要查询key为从18到49的所有数据记录，当找到18后，只需顺着节点和指针顺序遍历就可以一次性访问到所有数据节点，极大提到了区间查询效率(无需返回上层父节点重复遍历查找减少IO操作)。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 3][]

### 总结 ###

啰里啰唆一大堆，关键点来了也就是博文的核心Mysql主键为什么不推荐使用字符串：字符串太长了、占用空间大，作为主键性能太差了；更为关键点是，字符串不具有有序性，会导致 B+Tree索引在写的时候有过多的随机写操作（连续的 ID 可以产生部分顺序写），另外一点由于在写库的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+Tree节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显。观点就这么多总感觉这篇博文的主题不应该定为(Mysql主键为什么不推荐使用字符串)，呵呵希望各位有更好的建议。

**如有披露或问题欢迎留言或者入群探讨**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 4][]

[Mysql]: https://blog.csdn.net/qq_39470733/article/details/109326870
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70]: /images/20221120/0b4191a1f92541ff8383326906cc845d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20201030095853339.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20201030143547325.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz,size_16,color_FFFFFF,t_70
[20201030144032376.png]: https://img-blog.csdnimg.cn/20201030144032376.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/2020103014574353.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200521160806979.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz,size_16,color_FFFFFF,t_70