第142节课.mysql优化之什么是索引

从 MySQL 5.7 开始，开发人员改变了 InnoDB 构建二级索引的方式，采用自下而上的方法，而不是早期版本中自上而下的方法了。在这篇文章中，我们将通过一个示例来说明如何构建 InnoDB 索引。最后，我将解释如何通过为 innodb_fill_factor 设置更合适的值。

索引构建过程

在有数据的表上构建索引，InnoDB 中有以下几个阶段：1.读取阶段（从聚簇索引读取并构建二级索引条目）2.合并排序阶段3.插入阶段（将排序记录插入二级索引）在 5.6 版本之前，MySQL 通过一次插入一条记录来构建二级索引。这是一种“自上而下”的方法。搜索插入位置从树的根部（顶部）开始并达到叶页（底部）。该记录插入光标指向的叶页上。在查找插入位置和进行业面拆分和合并方面开销很大。从MySQL 5.7开始，添加索引期间的插入阶段使用“排序索引构建”，也称为“批量索引加载”。在这种方法中，索引是“自下而上”构建的。即叶页（底部）首先构建，然后非叶级别直到根（顶部）。

示例

在这些情况下使用排序的索引构建：

ALTER TABLE t1 ADD INDEX（or CREATE INDEX）

ALTER TABLE t1 ADD FULLTEXT INDEX

ALTER TABLE t1 ADD COLUMN, ALGORITHM = INPLACE

OPIMIZE t1

对于最后两个用例，ALTER 会创建一个中间表。中间表索引（主要和次要）使用“排序索引构建”构建。

算法

在 0 级别创建页，还要为此页创建一个游标

使用 0 级别处的游标插入页面，直到填满

页面填满后，创建一个兄弟页（不要插入到兄弟页）

为当前的整页创建节点指针（子页中的最小键，子页码），并将节点指针插入上一级（父页）

在较高级别，检查游标是否已定位。如果没有，请为该级别创建父页和游标

在父页插入节点指针

如果父页已填满，请重复步骤 3, 4, 5, 6

现在插入兄弟页并使游标指向兄弟页

在所有插入的末尾，每个级别的游标指向最右边的页。提交所有游标（意味着提交修改页面的迷你事务，释放所有锁存器）

为简单起见，上述算法跳过了有关压缩页和 BLOB（外部存储的 BLOB）处理的细节。

通过自下而上的方式构建索引

为简单起见，假设子页和非子页中允许的 最大记录数为 3

CREATE TABLE t1 (a INT PRIMARY KEY, b INT, c BLOB)

INSERT INTO t1 VALUES (1, 11, 'hello111')

INSERT INTO t1 VALUES (2, 22, 'hello222')

INSERT INTO t1 VALUES (3, 33, 'hello333')

INSERT INTO t1 VALUES (4, 44, 'hello444')

INSERT INTO t1 VALUES (5, 55, 'hello555')

INSERT INTO t1 VALUES (6, 66, 'hello666')

INSERT INTO t1 VALUES (7, 77, 'hello777')

INSERT INTO t1 VALUES (8, 88, 'hello888')

INSERT INTO t1 VALUES (9, 99, 'hello999')

INSERT INTO t1 VALUES (10, 1010, 'hello101010')

ALTER TABLE t1 ADD INDEX k1(b)

InnoDB 将主键字段追加到二级索引。二级索引 k1 的记录格式为(b, a)。在排序阶段完成后，记录为：

(11,1), (22,2), (33,3), (44,4), (55,5), (66,6), (77,7), (88,8), (99,9), (1010, 10)

初始插入阶段

让我们从记录 (11,1) 开始。

在 0 级别（叶级别）创建页

创建一个到页的游标

所有插入都将转到此页面，直到它填满了

箭头显示游标当前指向的位置。它目前位于第 5 页，下一个插入将转到此页面。

还有两个空闲插槽，因此插入记录 (22,2) 和 (33,3) 非常简单

对于下一条记录 (44,4)，页码 5 已满（前面提到的假设最大记录数为 3）。这就是步骤。

页填充时的索引构建

创建一个兄弟页，页码 6

不要插入兄弟页

在游标处提交页面，即迷你事务提交，释放锁存器等

作为提交的一部分，创建节点指针并将其插入到 【当前级别 + 1】 的父页面中（即在 1 级别）

节点指针的格式 (子页面中的最小键,子页码) 。第 5 页的最小键是 (11,1) 。在父级别插入记录 ((11,1)，5)。

1 级别的父页尚不存在，MySQL 创建页码 7 和指向页码 7 的游标。

将 ((11,1)，5) 插入第 7 页

现在，返回到 0 级并创建从第 5 页到第 6 页的链接，反之亦然

0 级别的游标现在指向兄弟页，页码为 6

将 (44,4) 插入第 6 页

下一个插入 - (55,5) 和 (66,6) - 很简单，它们转到第 6 页。

插入记录 (77,7) 类似于 (44,4)，除了父页面 （页面编号 7） 已经存在并且它有两个以上记录的空间。首先将节点指针 ((44,4),8) 插入第 7 页，然后将 (77,7) 记录到同级 8 页中。

插入记录 (88,8) 和 (99,9) 很简单，因为第 8 页有两个空闲插槽。

下一个插入 (1010,10) 。将节点指针 ((77,7),8) 插入 1级别的父页（页码 7）。

MySQL 在 0 级创建同级页码 9。将记录 (1010,10) 插入第 9 页并将光标更改为此页面。

以此类推。在上面的示例中，数据库在 0 级别提交到第 9 页，在 1 级别提交到第 7 页。

我们现在有了一个完整的 B+-tree 索引，它是自下至上构建的！

索引填充因子

全局变量 innodb_fill_factor 用于设置插入 B-tree 页中的空间量。默认值为 100，表示使用整个业面（不包括页眉）。聚簇索引具有 innodb_fill_factor=100 的免除项。 在这种情况下，聚簇索引也空间的 1 /16 保持空闲。即 6.25% 的空间用于未来的 DML。

值 80 意味着 MySQL 使用了 80% 的页空间填充，预留 20% 于未来的更新。如果 innodb_fill_factor=100 则没有剩余空间供未来插入二级索引。如果在添加索引后，期望表上有更多的 DML，则可能导致业面拆分并再次合并。在这种情况下，建议使用 80-90 之间的值。此变量还会影响使用 OPTIMIZE TABLE 和 ALTER TABLE DROP COLUMN, ALGOITHM=INPLACE 重新创建的索引。也不应该设置太低的值，例如低于 50。因为索引会占用浪费更多的磁盘空间，值较低时，索引中的页数较多，索引统计信息的采样可能不是最佳的。优化器可以选择具有次优统计信息的错误查询计划。

排序索引构建的优点

没有页面拆分（不包括压缩表）和合并

没有重复搜索插入位置

插入不会被重做记录（页分配除外），因此重做日志子系统的压力较小

缺点

ALTER 正在进行时，插入性能降低 Bug＃82940，但在后续版本中计划修复。

请点击输入图片描述

只要字段值还可以继续拆分，就不满足第一范式。

范式设计得越详细，对某些实际 *** 作可能会更好，但并非都有好处，需要对项目的实际情况进行设定。

在满足第一范式的前提下，其他列都必须完全依赖于主键列。 如果出现不完全依赖，只可能发生在联合主键的情况下：

实际上，在这张订单表中，product_name 只依赖于 product_id ，customer_name 只依赖于 customer_id。也就是说，product_name 和 customer_id 是没用关系的，customer_name 和 product_id 也是没有关系的。

这就不满足第二范式：其他列都必须完全依赖于主键列！

拆分之后，myorder 表中的 product_id 和 customer_id 完全依赖于 order_id 主键，而 product 和 customer 表中的其他字段又完全依赖于主键。满足了第二范式的设计！

在满足第二范式的前提下，除了主键列之外，其他列之间不能有传递依赖关系。

表中的 customer_phone 有可能依赖于 order_id 、 customer_id 两列，也就不满足了第三范式的设计：其他列之间不能有传递依赖关系。

修改后就不存在其他列之间的传递依赖关系，其他列都只依赖于主键列，满足了第三范式的设计！

查询每门课的平均成绩。

查询 score 表中至少有 2 名学生选修，并以 3 开头的课程的平均分数。

分析表发现，至少有 2 名学生选修的课程是 3-105 、3-245 、6-166 ，以 3 开头的课程是 3-105 、3-245。也就是说，我们要查询所有 3-105 和 3-245 的 degree 平均分。

查询所有学生的 name，以及该学生在 score 表中对应的 c_no 和 degree 。

通过分析可以发现，只要把 score 表中的 s_no 字段值替换成 student 表中对应的 name 字段值就可以了，如何做呢？

查询所有学生的 no 、课程名称 ( course 表中的 name ) 和成绩 ( score 表中的 degree ) 列。

只有 score 关联学生的 no ，因此只要查询 score 表，就能找出所有和学生相关的 no 和 degree ：

然后查询 course 表：

只要把 score 表中的 c_no 替换成 course 表中对应的 name 字段值就可以了。

查询所有学生的 name 、课程名 ( course 表中的 name ) 和 degree 。

只有 score 表中关联学生的学号和课堂号，我们只要围绕着 score 这张表查询就好了。

只要把 s_no 和 c_no 替换成 student 和 srouse 表中对应的 name 字段值就好了。

首先把 s_no 替换成 student 表中的 name 字段：

再把 c_no 替换成 course 表中的 name 字段：

查询 95031 班学生每门课程的平均成绩。

在 score 表中根据 student 表的学生编号筛选出学生的课堂号和成绩：

这时只要将 c_no 分组一下就能得出 95031 班学生每门课的平均成绩：

查询在 3-105 课程中，所有成绩高于 109 号同学的记录。

首先筛选出课堂号为 3-105 ，在找出所有成绩高于 109 号同学的的行。

查询所有成绩高于 109 号同学的 3-105 课程成绩记录。

查询所有和 101 、108 号学生同年出生的 no 、name 、birthday 列。

查询 '张旭' 教师任课的学生成绩表。

首先找到教师编号：

通过 sourse 表找到该教师课程号：

通过筛选出的课程号查询成绩表：

查询某选修课程多于5个同学的教师姓名。

首先在 teacher 表中，根据 no 字段来判断该教师的同一门课程是否有至少5名学员选修：

查看和教师编号有有关的表的信息：

我们已经找到和教师编号有关的字段就在 course 表中，但是还无法知道哪门课程至少有5名学生选修，所以还需要根据 score 表来查询：

根据筛选出来的课程号，找出在某课程中，拥有至少5名学员的教师编号：

在 teacher 表中，根据筛选出来的教师编号找到教师姓名：

查询 “计算机系” 课程的成绩表。

思路是，先找出 course 表中所有 计算机系 课程的编号，然后根据这个编号查询 score 表。

查询 计算机系 与 电子工程系 中的不同职称的教师。

查询课程 3-105 且成绩 至少 高于 3-245 的 score 表。

查询课程 3-105 且成绩高于 3-245 的 score 表。

查询某课程成绩比该课程平均成绩低的 score 表。

查询所有任课 ( 在 course 表里有课程 ) 教师的 name 和 department 。

查询 student 表中至少有 2 名男生的 class 。

查询 student 表中不姓 "王" 的同学记录。

查询 student 表中每个学生的姓名和年龄。

查询 student 表中最大和最小的 birthday 值。

以 class 和 birthday 从大到小的顺序查询 student 表。

查询 "男" 教师及其所上的课程。

查询最高分同学的 score 表。

查询和 "李军" 同性别的所有同学 name 。

查询和 "李军" 同性别且同班的同学 name 。

查询所有选修 "计算机导论" 课程的 "男" 同学成绩表。

需要的 "计算机导论" 和性别为 "男" 的编号可以在 course 和 student 表中找到。

建立一个 grade 表代表学生的成绩等级，并插入数据：

查询所有学生的 s_no 、c_no 和 grade 列。

思路是，使用区间 ( BETWEEN ) 查询，判断学生的成绩 ( degree ) 在 grade 表的 low 和 upp 之间。

准备用于测试连接查询的数据：

分析两张表发现，person 表并没有为 cardId 字段设置一个在 card 表中对应的 id 外键。如果设置了的话，person 中 cardId 字段值为 6 的行就插不进去，因为该 cardId 值在 card 表中并没有。

要查询这两张表中有关系的数据，可以使用 INNER JOIN ( 内连接 ) 将它们连接在一起。

完整显示左边的表 ( person ) ，右边的表如果符合条件就显示，不符合则补 NULL 。

完整显示右边的表 ( card ) ，左边的表如果符合条件就显示，不符合则补 NULL 。

完整显示两张表的全部数据。

在 MySQL 中，事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性 。

比如我们的银行转账：

在实际项目中，假设只有一条 SQL 语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。

因此，在执行多条有关联 SQL 语句时， 事务 可能会要求这些 SQL 语句要么同时执行成功，要么就都执行失败。

在 MySQL 中，事务的 自动提交 状态默认是开启的。

自动提交的作用 ：当我们执行一条 SQL 语句的时候，其产生的效果就会立即体现出来，且不能 回滚 。

什么是回滚？举个例子：

可以看到，在执行插入语句后数据立刻生效，原因是 MySQL 中的事务自动将它 提交 到了数据库中。那么所谓 回滚 的意思就是，撤销执行过的所有 SQL 语句，使其回滚到 最后一次提交 数据时的状态。

在 MySQL 中使用 ROLLBACK 执行回滚：

由于所有执行过的 SQL 语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？

将自动提交关闭后，测试数据回滚：

那如何将虚拟的数据真正提交到数据库中？使用 COMMIT :

事务的实际应用 ，让我们再回到银行转账项目：

这时假设在转账时发生了意外，就可以使用 ROLLBACK 回滚到最后一次提交的状态：

这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT 。

事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：

仍然使用 COMMIT 提交数据，提交后无法再发生本次事务的回滚。

事务的四大特征：

事务的隔离性可分为四种 ( 性能从低到高 ) ：

查看当前数据库的默认隔离级别：

修改隔离级别：

测试 READ UNCOMMITTED ( 读取未提交 ) 的隔离性：

由于小明的转账是在新开启的事务上进行 *** 作的，而该 *** 作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK 命令，会发生什么？

这就是所谓的 脏读 ，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。

把隔离级别设置为 READ COMMITTED ：

这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据，例如：

但是这样还有问题，那就是假设一个事务在 *** 作数据时，其他事务干扰了这个事务的数据。例如：

虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是 在读取同一个表的数据时，可能会发生前后不一致的情况。* 这被称为* 不可重复读现象 ( READ COMMITTED ) 。

将隔离级别设置为 REPEATABLE READ ( 可被重复读取 ) :

测试 REPEATABLE READ ，假设在两个不同的连接上分别执行 START TRANSACTION :

当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有 *** 作事务的连接。相当于开辟出一条单独的线程。

无论小张是否执行过 COMMIT ，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：

这是 因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) * ，那么* 在他的这条新事务的线上，跟其他事务是没有联系的 ，也就是说，此时如果其他事务正在 *** 作数据，它是不知道的。

然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？

报错了， *** 作被告知已存在主键为 6 的字段。这种现象也被称为 幻读，一个事务提交的数据，不能被其他事务读取到 。

顾名思义，就是所有事务的 写入 *** 作 全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE :

还是拿小张和小王来举例：

此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照 固定顺序执行 ，执行完一个事务后再继续执行下一个事务的 写入 *** 作 ( 这意味着队列中同时只能执行一个事务的写入 *** 作 ) 。

根据这个解释，小王在插入数据时，会出现等待状态，直到小张执行 COMMIT 结束它所处的事务，或者出现等待超时。

转载： https://github.com/baa-god/sql_node/blob/master/mysql/

零基础想要学习MySQL课程，慕课网我推荐阿里新零售数据库，这个老师讲的就还蛮不错的，我个人比较喜欢，他讲课小白听起来很舒服，而且条理清晰，能够化繁为简，把复杂的知识简单化，讲的非常细致，课程也很实用，有理论有实 *** 。不过学这门课最好有点基础，理解起来更容易，我看有没怎么学过的人买的，在问答区问题特别多。

---