mysql 理论知识

古城微笑少年丶 2024-04-01 13:17 98阅读 0赞

#### Mysql方面的知识 ####

*   *  MySQL 存储引擎
     *  MyISAM 和 InnoDB 的区别是什么？
     *  MySQL 事务
     *  SQL 标准定义了哪些事务隔离级别?
     *  数据库三大范式
     *  drop、delete 与 truncate 区别？
     *  索引的数据结构
     *  聚簇索引（聚集索引）和非聚簇索引（辅助索引）的区别

### MySQL 存储引擎 ###

--------------------

MySQL 核心在于存储引擎，想要深入学习 MySQL，必定要深入研究 MySQL 存储引擎。

**MySQL 支持哪些存储引擎？默认使用哪个？**  
MySQL 支持多种存储引擎，你可以通过 `show engines` 命令来查看 MySQL 支持的所有存储引擎。  
![在这里插入图片描述][7790939647e44040b6fe2da42bbdd298.png]  
从上图我们可以查看出， MySQL 当前默认的存储引擎是 `InnoDB`。并且，所有的存储引擎中只有 `InnoDB 是事务性`存储引擎，也就是说**只有 InnoDB 支持事务。**

你可以通过 `select version()` 命令查看你的 MySQL 版本。

mysql> select version();
    +-----------+
    | version() |
    +-----------+
    | 8.0.27    |
    +-----------+
    1 row in set (0.00 sec)

通过 `show variables like '%storage_engine%'` 命令直接查看 MySQL 当前默认的存储引擎  
![在这里插入图片描述][ffcdcd41d279446fa30aaa5f63aff573.png]  
只想查看数据库中某个表使用的存储引擎的话，可以使用 `show table status from db_name where name='table_name'`命令  
![在这里插入图片描述][b2235b533a8d4bdab6d53efc77fe29f5.png]

### MyISAM 和 InnoDB 的区别是什么？ ###

--------------------

*  1、`MyISAM` 只支持表级锁`(table-level locking)`，而 `InnoDB`支持**行级锁**(row-level locking)和**表级锁**，默认为行级锁。
 *  2、`MyISAM` 不支持事务，`InnoDB` 支持事务。  
    SQL 标准定义了四个隔离级别，具有提交(`commit`)和回滚(`rollback`)事务的能力。并且，`InnoDB` 默认使用的 `REPEATABLE-READ`（可重读）隔离级别是可以解决**幻读**问题发生的（基于 MVCC 和 Next-Key Lock）
 *  3、`MyISAM` 不支持外键，而 `InnoDB` 支持外键。
 *  4、`MyISAM` 不支持数据库异常崩溃后的安全恢复，而 `InnoDB` 支持数据库异常崩溃后的安全恢复。  
    使用 InnoDB 的数据库在异常崩溃后，数据库重新启动的时候会保证数据库恢复到崩溃前的状态。这个恢复的过程依赖于 `redo log` 。
 *  5、`MyISAM` 不支持`MVCC`，而 `InnoDB` 支持`MVCC`。

### MySQL 事务 ###

--------------------

**1、何谓事务？**  
我们设想一个场景，这个场景中我们需要插入多条相关联的数据到数据库，不幸的是，这个过程可能会遇到下面这些问题：

*  数据库中途突然因为某些原因挂掉了。
 *  客户端突然因为网络原因连接不上数据库了。
 *  并发访问数据库时，多个线程同时写入数据库，覆盖了彼此的更改。

**何为事务？** 一言蔽之，**事务是逻辑上的一组操作，要么都执行，要么都不执行**。  
事务最经典也经常被拿出来说例子就是转账了。假如小明要给小红转账 1000 元，这个转账会涉及到两个关键操作，这两个操作必须都成功或者都失败。  
1、将小明的余额减少 1000 元  
2、将小红的余额增加 1000 元。  
事务会把这两个操作就可以看成逻辑上的一个整体，这个整体包含的操作要么都成功，要么都要失败。这样就不会出现小明余额减少而小红的余额却并没有增加的情况。  
![在这里插入图片描述][36d0dc70be3646a69af80572a657ee34.png]  
**2、那数据库事务有什么作用呢？**

简单来说，数据库事务可以保证多个对数据库的操作（也就是 SQL 语句）构成一个逻辑上的整体。构成这个逻辑上的整体的这些数据库操作遵循：**要么全部执行成功,要么全部不执行** 。

# 开启一个事务
    START TRANSACTION;
    # 多条 SQL 语句
    SQL1,SQL2...
    ## 提交事务
    COMMIT;

![在这里插入图片描述][429955d4a7b3469c9eae25a2c9f66c4d.png]  
**3、事务的四大特性**

*  1、**原子性**（`Atomicity`） ： 事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用；
 *  2、**一致性**（`Consistency`）： 执行事务前后，数据保持一致，例如转账业务中，无论事务是否成功，转账者和收款人的总额应该是不变的；
 *  3、**隔离性**（`Isolation`）： 并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间数据库是独立的；
 *  4、**持久性**（`Durability`）： 一个事务被提交之后。它对数据库中数据的改变是持久的，即使数据库发生故障也不应该对其有任何影响。

**4、并发事务带来了哪些问题?**  
多个事务并发运行，经常会操作相同的数据来完成各自的任务（多个用户对同一数据进行操作）

*  **脏读**（`Dirty read`）:  
    当一个事务正在访问数据并且对数据进行了修改，而这种修改还没有提交到数据库中，这时另外一个事务也访问了这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是“脏数据”，依据“脏数据”所做的操作可能是不正确的。
 *  丢失修改（Lost to modify）: 指在一个事务读取一个数据时，另外一个事务也访问了该数据，那么在第一个事务中修改了这个数据后，第二个事务也修改了这个数据。这样第一个事务内的修改结果就被丢失，因此称为丢失修改。 例如：事务 1 读取某表中的数据 A=20，事务 2 也读取 A=20，事务 1 修改 A=A-1，事务 2 也修改 A=A-1，最终结果 A=19，事务 1 的修改被丢失。
 *  **不可重复读**（`Unrepeatable read`）:  
    指在一个事务内多次读同一数据。在这个事务还没有结束时，另一个事务也访问该数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改导致第一个事务两次读取的数据可能不太一样。这就发生了在一个事务内两次读到的数据是不一样的情况，因此称为不可重复读。
 *  **幻读**（`Phantom read`）:  
    幻读与不可重复读类似。它发生在一个事务（T1）读取了几行数据，接着另一个并发事务（T2）插入了一些数据时。在随后的查询中，第一个事务（T1）就会发现多了一些原本不存在的记录，就好像发生了幻觉一样，所以称为幻读。

**不可重复读和幻读有什么区别呢？**

*  **不可重复读**的重点是**内容修改**或者记录减少比如多次读取一条记录发现其中某些记录的值被修改；
 *  **幻读**的重点在于记录**新增**比如多次执行同一条查询语句（DQL）时，发现查到的记录增加了。

--------------------

### SQL 标准定义了哪些事务隔离级别? ###

**1、SQL 标准定义了四个隔离级别：**

*  `READ-UNCOMMITTED`(**读取未提交**) ： 最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
 *  `READ-COMMITTED`(**读取已提交**) ： 允许读取并发事务已经提交的数据，可以阻止**脏读**，但是幻读或不可重复读仍有可能发生。
 *  `REPEATABLE-READ`(**可重复读**) ：  
    对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以**阻止脏读**和**不可重复读**，但幻读仍有可能发生。
 *  `SERIALIZABLE`(**可串行化**) ： 最高的隔离级别，完全服从 ACID  
    的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别**可以防止脏读、不可重复读以及幻读**。

**2、MySQL 的默认隔离级别是什么?**  
MySQL InnoDB 存储引擎的默认支持的隔离级别是 `REPEATABLE-READ`（**可重读**）  
MySQL 8.0 该命令改为`SELECT @@transaction_isolation;`

mysql> SELECT @@transaction_isolation;
    +-------------------------+
    | @@transaction_isolation |
    +-------------------------+
    | REPEATABLE-READ         |
    +-------------------------+
    1 row in set (0.00 sec)

### 数据库三大范式 ###

--------------------

范式是数据库设计时遵循的一种规范，不同的规范要求遵循不同的范式。

**1NF(第一范式)**  
属性不可分割，即每个属性都是**不可分割的原子项**。(实体的属性即表中的列)

**第二范式(2NF)**：  
满足第一范式；且不存在部分依赖，即**非主属性必须完全依赖于主属性**。(主属性即主键；完全依赖是针对于联合主键的情况，非主键列不能只依赖于主键的一部分)

**第三范式(3NF)：**  
满足第二范式；且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。（A -> B, B ->C, A -> C）

**二、举例说明**

**1、1NF**  
不符合第一范式的表：属性还可以再分割  
![在这里插入图片描述][abe9a5093c5644a4b85df96987deee12.png]  
**修改后的表**：每个字段原子性，不可再分割  
![在这里插入图片描述][5b131571c7ba44fbbab3816f897730fa.png]  
**2、2NF**  
在满足1NF的前提下，表中不存在部分依赖，非主键列要完全依赖于主键。(主要是说在联合主键的情况下，非主键列不能只依赖于主键的一部分)

**注意**：这张表中的`stu_id`和`kc_id`构成了联合主键。`score`没问题，它完全依赖于联合主键，`stu_id`和`kc_id`两个值才能决定`score`的值。但是`kc_name`只依赖于`kc_id`，这是部分依赖关系，不符合第二范式。  
![在这里插入图片描述][eb82b93e97b8475aa9728dd04527b753.png]  
**修改后的表**：分为两张表，每张表都符合第二范式。  
![在这里插入图片描述][ec192e45de34419e903530ef4879f700.png]  
![在这里插入图片描述][3eb97f9b3f924cd6a0808950d85a58e3.png]  
**3、3NF**  
在满足2NF的前提下，不存在传递依赖。(A -> B, B -> C, A->C)  
`sex_desc`不直接依赖于主键，而是通过依赖于非主键列而依赖于主键，属于传递依赖，不符合3NF。(id -> sex\_code -> sex\_desc)  
![在这里插入图片描述][548cf82131c94e4b815f409f66d74a42.png]  
**修改后的表**：分为两张表，每张表都符合第三范式。

![在这里插入图片描述][7eb5628648634447ac23cdc617bcd835.png]  
![在这里插入图片描述][4c432060030f446c867aeaf706b04f80.png]

--------------------

### drop、delete 与 truncate 区别？ ###

**用法不同**

*  `drop`(丢弃数据): `drop table 表名` ，直接将表都删除掉，在删除表的时候使用。
 *  `truncate` (清空数据) : `truncate table 表名` ，只删除表中的数据，再插入数据的时候自增长 id 又从 1 开始，在清空表中数据的时候使用。
 *  `delete`（删除数据） : `delete from 表名 where 列名=值`，删除某一行的数据，如果不加 where 子句和`truncate table 表名`作用类似。

truncate 和不带 where 子句的 delete、以及 drop 都会删除表内的数据，但是 **truncate 和 delete 只删除数据不删除表的结构(定义)，执行 drop 语句，此表的结构也会删除，也就是执行 drop 之后对应的表不复存在**。

### 索引的数据结构 ###

**一、为什么使用索引**

**索引**是存储引擎用于快速找到数据记录的一种`数据结构`，就好比一本教科书的目录部分（也不太一样），通过目录中找到对应文章的页码，便可快速定位到需要的文章。  
Mysql中也是一样的道理，进行数据查找时，首先查看条件是否命中某条索引，符合则`通过索引查找`相关数据，如果不符合则需要`全表扫描`，即需要一条一条地查找记录，直到找到与条件符合的记录。  
![在这里插入图片描述][5a9c74a1d8bd46619ed4084c79d1a430.png]  
如上图所示，数据库没有索引的情况下，数据`分布在硬盘不同的位置上面`，读取数据时，摆臂需要前后摆动查找数据，这样操作非常消耗时间。如果`数据顺序摆放`，那么也需要从1到6行按顺序读取，这样就相当于进行了6次IO操作，`依旧非常耗时`。如果我们不借助任何索引结构帮助我们快速定位数据的话，我们查找Col2 = 89 这条记录，就要逐行去查找、去比较。从 Col 2 = 34 开始，进行比较，发现不是，继续下一行。我们当前的表只有不到10行数据，但如果表很大的话，有`上千万条数据`，就意味着要做`很多很多次磁盘I/O`才能找到。现在要查找Col2=89这条记录。CPU必须先去磁盘查找这条记录，找到之后加载到内存，再对数据进行处理。这个过程最耗时间的就是磁盘I/O（涉及到磁盘的旋转时间（速度较快）、磁头的寻找时间速度慢、费时）

假如给数据使用`二叉树`这样的数据结构进行存储，如下图所示：  
![在这里插入图片描述][480184644c4a4235af892217cf15605d.png]  
对字段Col2添加了索引，就相当于在硬盘上为Col2维护了一个索引的数据结构，即这个`二叉搜索树`。二叉搜索树和的每个节点存储的是`（k，v）结构`，key是Col2，value是该key所在行的文件指针（地址）。比如：该二叉搜索树的根节点就是：`（34,0x07）`。现在对Col2添加了索引，这时再去查找Col2=89这条记录的时候会先去查找二叉树（二叉树的遍历查找）。读34到内存，89>34;继续右侧数据，读到89到内存，89==89；找到数据返回。找到之后就根据当前节点的value快速定位到要查找的记录对应的地址。我们可以发现，只需要`查找两次`就可以定位到记录的地址，查询速度就提高了。

这就是我们为什么要建索引，目的就是为了`减少磁盘I/O的次数`，加快查询效率。

**二、索引及其优缺点**

**1、索引概述**

MySQL官方对索引的定义为：`索引（Index）是帮助MySQL高效获取数据的数据结构`。

**索引的本质**：索引是数据结构。你可以简单理解为“排好序的快速查找数据结构”，满足特定查找算法。这些数据结构以某种方式指向数据， 这样就可以在这些数据结构的基础上实现 `高级查找算法`。

`索引是在存储引擎中实现的`，因此每种存储引擎的索引不一定完全相同，并且每种存储引擎不一定支持所有索引类型。同时，存储引擎可以定义每个表的`最大索引数`和`最大索引长度`。所有存储引擎支持每个表至少16个索引，总索引长度至少256字节。有些存储引擎支持更多的索引数和更大的索引长度。

**2、 优点**

> （1）类似大学图书馆建书目索引，提高数据检索的效率，降低 `数据库的IO成本` ，这也是创建索引最主要的原因。  
> （2）通过创建唯一索引，可以保证数据库表中每一行 `数据的唯一性` 。  
> （3）在实现数据的参考完整性方面，可以 `加速表和表之间的连接`。换句话说，对于有依赖关系的子表和父表联合查询时，可以提高查询速度。  
> （4）在使用分组和排序子句进行数据查询时，可以显著 `减少查询中分组和排序的时间` ，降低了CPU的消耗。

**3、缺点**

> （1）创建索引和维护索引要 `耗费时间` ，并且随着数据量的增加，所耗费的时间也会增加。  
> （2）索引需要占 `磁盘空间`，除了数据表占数据空间之外，每一个索引还要占一定的物理空间， 存储在磁盘上 ，如果有大量的索引，索引文件就可能比数据文件更快达到最大文件尺寸。  
> （3）虽然索引大大提高了查询速度，同时却会 `降低更新表的速度` 。当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。

**提示**：

索引可以提高查询速度，但是会影响插入记录的速度。这种情况下，最好的办法是先删除表中的索引，然后插入数据，插入完成后再创建索引。

**三、InnoDB中索引的推演**

**1、索引之前的查找**  
先来看一个精确匹配的例子：

SELECT [列名列表] FROM 表名 WHERE 列名 = xxx;

**①在一个页中的查找**  
假设目前表中的记录比较少，所有的记录都可以被存放到一个页中，在查找记录的时候可以根据搜索条件的不同分为两种：

*  以主键为搜索条件  
    可以在页目录中使用`二分法`快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
 *  以其他列作为搜索条件  
    因为在数据页中并没有对非主键列建立所谓的页目录，所以我们无法通过二分法快速定位相应的槽。这种情况下只能从`最小记录`开始`以此遍历`单链表的每条记录，然后对比每条记录是不是符合搜索条件。很显然，这种查找的效率是非常低的。

**②在很多页中查找**  
大部分情况下我们表中存放的记录都是非常多的，需要好多的数据页来存储这些记录。在很多页中查找记录的话，可以分为两个步骤：

*  1、定位到记录所在的页。
 *  2、从所在的页中查找相应的记录。

在没有索引的情况下，不论是根据主键列或者其他列的值进行查找，由于我们并不能快速的定位到记录  
所在的页，所以只能 `从第一个页`沿着 `双向链表`一直往下找，在每一个页中根据我们上面的查找方式去查找指定的记录。因为要遍历所有的数据页，所以这种方式显然是 `超级耗时`的。如果一个表有一亿条记录呢？此时 `索引` 应运而生。

**2、设计索引**  
建一个表：

CREATE TABLE index_demo(
        c1 INT,
        c2 INT,
        c3 CHAR(1),
        PRIMARY KEY(c1)
      ) ROW_FORMAT = Compact;

这个新建的`index_demo`表中有2个INT类型的列，1个CHAR(1)类型的列，而且我们规定了c1列为主键，这个表使用 `Compact` 行格式来实际存储记录的。这里我们简化了index\_demo表的行格式示意图：  
![在这里插入图片描述][4395c3962da248d9aa3346fa7dd1c7d1.png]  
我们只在示意图里展示记录的这几个部分:

*  `record_type` ：记录头信息的一项属性，表示记录的类型， 0 表示普通记录、 2 表示最小记录、 3 表示最大记录、 1  
    暂时还没用过，下面讲。
 *  `next_record`：记录头信息的一项属性，表示下一条地址相对于本条记录的地址偏移量，我们用箭头来表明下一条记录是谁。
 *  `各个列的值` ：这里只记录在 `index_demo` 表中的三个列，分别是 `c1 、 c2 和 c3 。`
 *  `其他信息` ：除了上述3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息。

将记录格式示意图的其他信息项暂时去掉并把它竖起来的效果就是这样：  
![在这里插入图片描述][30d805fddb474354bafb8f8d14969fba.png]  
把一些记录放到页里的示意图就是：  
![在这里插入图片描述][d62bf510476649c3bcb969729a459c42.png]  
**①一个简单的索引设计方案**  
我们在根据某个搜索条件查找一些记录时为什么要遍历所有的数据页呢？因为各个页中的记录并没有规  
律，我们并不知道我们的搜索条件匹配哪些页中的记录，所以不得不依次遍历所有的数据页。所以如果我们 `想快速的定位到需要查找的记录在哪些数据页` 中该咋办？我们可以为快速定位记录所在的数据页而建立一个目录 ，建这个目录必须完成下边这些事：

*  **下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值**。  
    假设：每个数据页最多能存放3条记录（实际上一个数据页非常大，可以存放好多记录）。有了这个假设之后我们向 index\_demo 表中插入3条记录；

insert into index_demo values(1, 4, 'u'),(3, 9, 'd'),(5, 3, 'y')

那么这些记录已经按照主键值的大小串联成一个单向链表了，如图所示：  
![在这里插入图片描述][d8c988f28bff4f9381f23756bc7e14d6.png]  
从图中可以看出，index\_demo 表中的3条记录都被插入到编号为10的数据页中，此时我们再次插入一条记录：

insert into index_demo value (4,4,'a')

因为页10最多只能放3条记录，所以我们不得不再分配一个新页：  
![在这里插入图片描述][0d6b2f12fc1b48839407d1222bc91c87.png]  
注意，新分配的数据页编号可能并不是连续的。他们只是通过维护着上一个页和下一个页的编号而建立了链表关系。另外，页10 中用户记录最大的主键是5，而页28中有一条记录的主键4，因为 5>4,所以这就不符合下一个数据页中用户记录的主键值必须大于上一页中用户记录的主键值的要求，所以在插入主键值4的记录的时候需要伴随这一次记录移动，也就是把主键值为5的记录移动到28页中，然后把主键值为4的记录插入到页10中，这个过程示意图如下：  
![在这里插入图片描述][6acb4888c1c04ae59e59b58d491445d5.png]  
这个过程表明了在对页中的记录进行增删改查操作的过程中，我们必须通过一些诸如记录移动的操作来始终保证这个状态一直成立：下一个数据页中用户记录的主键值必须大于上一页中用户记录的主键值。这个过程我们称为分页裂。

*  **给所有的页建立一个目录项。**  
    由于数据页的编号可能是不连续的，所以在向 index\_demo 表中插入许多条记录后，可能是这样的效果：  
    ![在这里插入图片描述][fcd28ad6b25e428a887db4f34d3b08aa.png]  
    因为这些 16kb 的页在物理存储上是 不连续的，所以如果想从这么多页中根据主键值 快速定位某些记录所在的页，我们需要给他们做个目录，每个页对应一个目录项，每个目录项包括下边两个部分：
    
     *  页的用户记录中最小的主键值，我们用key 来表示
     *  页号，我们用 page\_no表示

所以我们为上边几个页做好的目录就像这样子：  
![在这里插入图片描述][ceaf1320cb0c45da9ae1f1ec2ac3ade9.png]  
以 `页28` 为例，它对应 `目录项2` ，这个目录项中包含着该页的页号 `28` 以及该页中用户记录的最小主键值 5 。我们只需要把几个目录项在物理存储器上连续存储（比如：数组），就可以实现根据主键值快速查找某条记录的功能了。比如：查找主键值为 `20` 的记录，具体查找过程分两步：

1、先从目录项中根据 `二分法` 快速确定出主键值为 `20` 的记录在 `目录项3` 中（因为 `12 < 20 < 209` ），它对应的页是 `页9` 。  
2、再根据前边说的在页中查找记录的方式去 `页9` 中定位具体的记录。  
至此，针对数据页做的简易目录就搞定了。这个目录有一个别名，称为 `索引` 。

**②InnoDB中的索引方案**

**迭代1次：目录项纪录的页**  
上边称为一个简易的索引方案，是因为我们为了在根据主键值进行查找时使用 二分法 快速定位具体的目录项而 假设所有目录项都可以在物理存储器上连续存储，但这样做有几个问题：

*  InnoDB是使用页来作为管理存储空间的基本单位，做多能保证 16kb 的连续存储空间，而随着表中记录数量的增多，需要  
    非常大的连续的存储空间 才能把所有的目录项都放下，这对记录数量非常多的表是不现实的。
 *  我们时常会对记录进行增删，假设我们把页28中的记录删除了，那意味着目录项2  
    也就没有存在的必要了，这就需要把目录项2后的目录项都向前移动一下，这样牵一发而动全身的操作效率很差；

所以，我们需要一种可以 灵活管理所有目录项 的方式，我们发现目录项其实长得跟我们的用户记录差不多，只不过目录项中的两个列是主键 和 页号 而已，为了和用户记录做一个区分，我们把这些用来表示目录项的记录称为目录项记录。那么InnoDB怎么区分一条记录是普通的用户记录 还是 目录项记录呢？使用记录信息里面的 record\_type 属性，它的各个取值代表的意思如下：

*  0：普通的用户记录
 *  1：目录项记录
 *  2：最小记录
 *  3：最大记录

我们把前边使用到的目录项放到数据页中的样子就是这样：  
![在这里插入图片描述][d32ed995232746d08a11f23fafa7aee3.png]  
从图中可以看出来，我们新分配了一个编号为30的页来专门存储目录项记录。这里再次强调 `目录项记录`和普通的 `用户记录` 的**不同点**：

*  `目录项记录` 的 `record_type` 值是1，而 `普通用户记录` 的 `record_type` 值是0。
 *  目录项记录只有 `主键值和页的编号` 两个列，而普通的用户记录的列是用户自己定义的，可能包含 `很多列` ，另外还有InnoDB自己添加的隐藏列。
 *  了解：记录头信息里还有一个叫`min_rec_mask` 的属性，只有在存储 `目录项记录`的页中的主键值 最小的 `目录项记录` 的  
    `min_rec_mask`值为1，其他别的记录的 `min_rec_mask`值都是 0。

**相同点**：两者用的是一样的数据页，都会为主键值生成 `Page Directory`（页目录），从而在按照键  
值进行查找时可以使用 `二分法` 来加快查询速度。

现在以查找主键为 `20` 的记录为例，根据某个主键值去查找记录的步骤就可以大致拆分成下边两步：

1、先到存储 `目录项记录` 的页，也就是页30中通过 `二分法` 快速定位到对应目录项，因为 `12 < 20 < 209` ，所以定位到对应的记录所在的页就是页9。  
2、再到存储用户记录的页9中根据 `二分法` 快速定位到主键值为 `20` 的用户记录。

--------------------

### 聚簇索引（聚集索引）和非聚簇索引（辅助索引）的区别 ###

InnoDB的默认数据结构是**聚簇索引**，而MyISAM默认的数据结构是**非聚簇索引**  
在 MySQL 默认引擎 InnoDB 中，索引大致可分为两类：

*  聚簇索引
 *  非聚簇索引

**聚簇索引**（Clustered Index）一般指的是**主键索引**（如果存在主键索引的话），聚簇索引也被称之为`聚集索引`。

如果表中没有定义主键，InnoDB 会选择一个唯一且非空的索引代替。
    	如果没有这样的索引，InnoDB 会隐式定义一个主键（类似oracle中的RowId）来作为聚簇索引。
    	如果已经设置了主键为聚簇索引又希望再单独设置聚簇索引，必须先删除主键，然后添加我们想要的聚簇索引，最后恢复设置主键即可。

聚簇索引将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据，并不是一种单独的索引类型，而是一种数据存储方式。

**非聚簇索引**

[7790939647e44040b6fe2da42bbdd298.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b2e595189ad943aa999e29825437f1a8.png
[ffcdcd41d279446fa30aaa5f63aff573.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5644eee1433d46a491ae470b546546ff.png
[b2235b533a8d4bdab6d53efc77fe29f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/43f40e18a0f24060b259c2d8d07aabb9.png
[36d0dc70be3646a69af80572a657ee34.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/a50345ce540448b595d18ad8eba14751.png
[429955d4a7b3469c9eae25a2c9f66c4d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/4ab05dfa3c62492d8039988f6498badc.png
[abe9a5093c5644a4b85df96987deee12.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2630137997f044eb94d58342598342fa.png
[5b131571c7ba44fbbab3816f897730fa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/44f05917a35e4b45a1f7b662e91e51bd.png
[eb82b93e97b8475aa9728dd04527b753.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/0359bf36870a479884b88509b7a15914.png
[ec192e45de34419e903530ef4879f700.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/02b6a959055948aaadc16d8d4cde9a97.png
[3eb97f9b3f924cd6a0808950d85a58e3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9b20c9f7ecb7465694811a3f73513742.png
[548cf82131c94e4b815f409f66d74a42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/fe849af81f79453585285caa2df6c295.png
[7eb5628648634447ac23cdc617bcd835.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/3e2eaafa018249dbb430d26be59096e9.png
[4c432060030f446c867aeaf706b04f80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c0f433408ffc4c9eabf744629f81d952.png
[5a9c74a1d8bd46619ed4084c79d1a430.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d62a521c1ab34601ace1bd80e25ef59e.png
[480184644c4a4235af892217cf15605d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/910248b8a78e4657a83a44db2dd68333.png
[4395c3962da248d9aa3346fa7dd1c7d1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d9c7464e6c6c4e38ae0f81b65739a549.png
[30d805fddb474354bafb8f8d14969fba.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e0becb14efbf417bb928a751852936e5.png
[d62bf510476649c3bcb969729a459c42.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5d314d0c9c99467ca780be0997e7b344.png
[d8c988f28bff4f9381f23756bc7e14d6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/c66d0b32f5354ebf965511fab49dc207.png
[0d6b2f12fc1b48839407d1222bc91c87.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2a93c398bc8f44fa8aa080642336ed3a.png
[6acb4888c1c04ae59e59b58d491445d5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2a5de9f346194eb78b352e5915025c4c.png
[fcd28ad6b25e428a887db4f34d3b08aa.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/40ec445f0ffe4b9cbfe6608c360236cf.png
[ceaf1320cb0c45da9ae1f1ec2ac3ade9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/5e6b75e00db14a16ab778ba1c4b59abf.png
[d32ed995232746d08a11f23fafa7aee3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/7f8fa5d0bb884e4e8a9bfb5bdd663503.png