当前位置：首页 > news >正文

【MySQL】MySQL索引与事务

news 来源：原创 2025/4/26 5:44:18

前言

1. 索引（index）

1.1 概念

1.2 作用

1.3 使用场景

1.4 索引的相关操作

查看索引

创建索引

删除索引

2. 索引背后的数据结构

2.1 B+树

2.2 B＋树的特点

2.3 B＋树的优势

3. 事务

3.1 为什么使用事务

3.2 事务的概念

3.3 使用事务

3.4 事务四大关键特性

4. 事务隔离性解决并发问题

4.1 脏读问题

4.2 不可重复读

4.3 幻读

4.4 隔离级别

前言

数据库使用 select 查询的时候：

先遍历表
把当前的行给带入到条件中，看条件是否成立
条件成立，这样的行就保留。不成立就跳过。

如果表非常的小，正常使用没问题。如果表非常大，这样的遍历成本就比较高了。
站在时间复杂度角度，至少是O(N)。时间复杂度和空间复杂度都是基于内存的计算的。
数据库是把数据存储在硬盘上，每次读取一个数据都需要读取硬盘。
读取硬盘这个操作，开销本身就是很大的。读写一次硬盘开销远远大于读1次内存。读1次硬盘相当于读1万次内存。频繁进行读取更是慢上加慢。
所以就引出了索引，增加遍历查询速度，减少硬盘的访问次数。

1. 索引（index）

索引英文是 index。这里的 index 指的是索引，并不是数组下标。

1.1 概念

索引是一种特殊的文件，包含着对数据表里所有记录的引用指针。可以对表中的一列或多列创建索引，并指定索引的类型，各类索引有各自的数据结构实现。（具体细节在后续的数据库原理课程讲解）

1.2 作用

索引属于是针对查询操作引入的优化手段。可以通过索引来加快查询的速度，避免针对表进行遍历。
数据库中的表、数据、索引之间的关系，类似于书架上的图书、书籍内容和书籍目录的关系。
索引所起的作用类似书籍目录，可用于快速定位、检索数据。

缺陷

索引会占用额外的磁盘空间，付出额外空间代价来保存索引数据。生成索引，是需要一系列的数据结构，以及一系列的额外的数据，来存储到硬盘空间中的。
索引加快了查询速度，但可能会拖慢新增，删除，修改的速度。因为新增、删除、修改数据还需要同步新增、删除、修改索引，产生额外的开销。

整体来说，还是认为索引是利大于弊的， 实际开发中，查询(读)场景一般要比增删改(写)频率高很多。

1.3 使用场景

要考虑对数据库表的某列或某几列创建索引，需要考虑以下几点：

数据量较大，且经常对这些列进行条件查询。
该数据库表的插入操作，及对这些列的修改操作频率较低。
不太在意，索引占用额外的磁盘空间。

满足以上条件时，考虑对表中的这些字段创建索引，以提高查询效率。

反之，如果非条件查询列，或经常做插入、修改操作，或磁盘空间不足时，不考虑创建索引。

1.4 索引的相关操作

创建主键约束（PRIMARY KEY）、唯一约束（UNIQUE）、外键约束（FOREIGN KEY）时，会自动创建对应列的索引。

为什么创建这三个约束，会自动创建对应列的索引：

primary key 和 uniqe 都是要求对应列的记录不能重复，每次插入/修改被约束列的数据，需要查询判断是否重复。涉及频繁的查询操作。优化查询速度，自动引入索引，查询跟着索引走就不需要一条条记录去遍历了，大大加快了插入/修改的速度。
foreign key 约束的时候，子表中对应的记录要在父表中存在。往子表中插入/修改对应约束列的数据时，就需要每次查询父表中是否存在。反之，从父表中修改/删除数据时，也需要查询该数据在子表中是否被引用。涉及频繁的查询操作。优化查询速度，自动引入索引。

查看索引

primary key 主键自动生成的索引

可以理解为：student表中内容，根据id列生成了一份目录；这里自动创建的索引名为primary

索引表中的列大概认识一下，不需要全部了解。
一个索引是针对一个列来指定的。
只有针对这一列进行条件查询的时候，查询速度才能够被索引优化。

例如：

此处针对 id 创建索引。使用id进行条件查询，速度是很快。
select * from student where id = 100; —— 使用索引，不需要一条条记录遍历。
select * from student where name = '张三'; —— 仍然需要遍历表。

unique 自动生成的索引

foreign key 外键自动生成的索引

一本书可以有多个目录。一个表也可以有多个索引。
例如：一个字典，目录有多种。拼音目录、笔画目录、部首目录、难检字目录。

创建索引

对于非主键、非唯一约束、非外键的字段，可以创建普通索引。

创建索引操作，也是一个危险操作；创建索引的时候，需要针对现有的数据，进行大规模的重新整理。如果当前表是一个空表或者数据不多，创建索引都没有问题。但如果这个表很大，创建索引开销会很大，很容易就把数据库服务器给卡住。
例如：有一本很厚的书，现在给这个书手动的写一份目录出来。好的做法，是创建表之初就把索引设定好。
一般来说，创建索引，在创建表时已经规划好了。如果表使用了很久，有很多数据，再想创建索引，就要慎重了。
如果表很大，坚持要创建索引，使用“移花接木”的技巧方式，尤其是生产环境(线上)的数据库。做法：在另外一台机器部署mysql服务器，创建同样的表，并且把表上的索引创建好，再把之前的机器上的数据给导入到新的mysql服务器上。控制导入数据过程的节奏，多花点时间导数据，不要影响到原来服务器正常的运转。当所有数据都导入完毕，就可以使用新的数据库，替换旧的数据库了。

删除索引

手动创建的索引，可以手动删除。自动创建的索引(主键/外键，unique)，不可以删除。

和创建索引类似，删除索引也是一个危险操作。理由同上。

2. 索引背后的数据结构

索引是通过一定的数据结构来实现的。哪些数据结构能加快查询的速度，B＋树，为数据库量身定做的数据结构。

mysql的索引的数据结构为什么不能是顺序表，链表，栈，队列，红黑树，哈希表呢?

1. 顺序表

在顺序表中间插入或删除元素需要移动大量数据，效率较低。

当容量不足时，需要重新分配更大的存储空间，并拷贝所有数据。

在大规模数据中进行随机查询效率低，尤其是当数据需要排序时。

2. 链表

链表不支持随机访问，必须从头开始遍历，查询时间复杂度是 O(n)。

每个节点需要额外的指针存储，内存开销较高。

链表不能快速进行范围查询。

3. 栈、队列、堆

栈和队列只适合用于简单的顺序操作，不支持高效的随机查询、范围查询或复杂操作。

栈和队列不支持快速的插入、删除或排序操作。

4. 红黑树

里面元素是有序，可以处理精准查询、范围查询、也能一定程度的模糊匹配。

最大的问题, 在于红黑树是二叉树(平衡)，每个节点最多两个子树，树的分叉少(结点的度少)，表示同样数量的结果集合，树的高度就会更高。意味着查询操作时，比较次数就会变得多，索引这样的结构是存储在硬盘上的，每一次比较就意味着硬盘IO操作。数据库引入的索引是一个改进的树形结构，B+树(N叉搜索树)。

5. 哈希表

不适合数据库的查询场景。因为哈希表只能做这种精准查询，无法做到范围查询和模糊查询。

红黑树(二叉搜索树)和哈希表都能提高查询速度，但是并不适合数据库的查询场景。

要了解B+树需要先了解下B树，B树有的时候会写作B - 树，不是B减树仍是B树的意思。 '-' 是连接符的意思，不是数学中的减符号。

B树的核心思路和"二叉搜索树"差不多。B树本质上是一个N叉搜索树。

每个节点的度都是不确定的。当节点的子树多了以及节点上保存的key多了，意味着在同样key 的个数的前提下，B树的高度就要比二叉搜索树低很多，树的高度越低，进行查询比较的时候访问磁盘的次数就越少，速度就大大提升。
B树的查询基本思路与二叉搜索树的查询思路是相似的，只不过B树是分了N叉，每个节点需要进行多次比较，确定走哪个区间，从而走哪个子树。
一个节点上保存N个key就划分出N＋1个区间。每个区间都可以衍生出一系列的子树了。树的高度就大幅度的降低了。
由于每个节点是在一个硬盘的区域中，一次读硬盘就读取出了整个节点(多个key )再进行几次比较。(读一次硬盘，相当于内存中1w次比较)
一个节点中，虽然是可以保存N个key，也不是无限制的，达到一定的规模，就会触发节点的分裂。当删除元素达到一定的数目，也会触发节点的合并（简化树形结构）。
具体什么时候进行拆分，怎么拆分；具体什么时候合并，怎么合并。实际的实现中，不同的场景下可以使用不同的策略。

2.1 B+树

B＋树，在B树的基础上又做出改进（也是N叉搜索树），针对数据库量身定做的。

整个树的所有数据都是包含在叶子节点中的（所有非叶子节点中的key最终都会出现在叶子节点中）
上述这个结构，是默认id是表的主键，如果这个表里有多个索引呢?
针对id是主键创建索引，表的数据还是按照 id为主键，构建出B＋树通过叶子节点组织所有的数据行。
其次，针对 name这一列，则会构建另外一个B+树，但是这个B+树的叶子节点就不再存储这一行的完整数据，而是存主键id是啥，此时，如果你根据name来查询，查到叶子节点得到的只是主键id，还需要再通过主键id去主键的B＋树里再查一次（查两次B+树），上述过程称为“回表"，这个过程，都是mysql自动完成的，用户感知不到。
上面的这个树形结构，是"索引"，如果这一列不能比较，就没法建立索引；幸运的是, mysql里的各种类型都能比较，数字、字符串、时间日期。故mysql中不支持自定义类型

2.2 B＋树的特点

一个节点，可以存储N 个key，N个key划分出了N个区间（而不是B树中的N＋1个区间）
每个节点中的key的值，都会在子节点中也存在（同时该key是子节点的最大值，也可以是最小值）
B＋树的叶子节点，是首尾相连，类似于一个链表
由于叶子节点是完整的数据集合，所以只在叶子节点这里存储数据表中的每一行的数据，而非叶子节点，只存key值本身即可。

2.3 B＋树的优势

1、当前一个节点保存更多的 key，最终树的高度是相对更矮的，查询的时候减少了IO访问次数（和B树是一样的）这里IO特指硬盘的访问

2、所有的查询最终都会落到叶子节点上（查询任何一个数据，经过的IO访问次数，是一样的）

这个相同次数很关键，稳定的能够让程序猿对于程序的执行效率有一个更准确的评估。

3、B+树的所有的叶子节点，构成链表，此时比较方便进行范围查询。

例如：查询学号>5并且<11的同学。只需要先找到5所在的位置，在找到11所在位置从5沿着链表遍历到11，中间结果即为所求，非常方便非常高效。

4、由于数据都在叶子节点上，非叶子节点只存储key，导致非叶子节点占用空间是比较小的，这些非叶子节点就可能在内存中缓存（或者是缓存一部分），又进一步减少了IO的次数。常量池本质上就是缓存。

例如：假设一个整数按照4个字节算，10亿个这样的整数，占据多大内存空间？(估算即可，不用精确)10亿个这样的 key才不到4G，4G对于计算机内存来说还是非常容易的。

带有索引的数据， mysql 组织数据就是B+树的方式；当你看到一张"表”的时候，实际上这个表不一定就是按照"表格"这样的数据结构在硬盘上组织的，也有可能是按照这种树形结构组织。具体是哪种结构，取决于你的表里有没有索引，以及数据库使用了哪种存储引擎。

3. 事务

3.1 为什么使用事务

开发中经常会涉及到一些场景，需要“一气呵成”的完成一些操作。

【案例】

准备测试表：

drop table if exists accout;
create table accout(id int primary key auto_increment, name varchar(20) comment '账户名称', money decimal(11,2) comment '金额');
insert into accout(name, money) values('阿里巴巴', 5000),('四十大盗', 1000);

比如说，四十大盗把从阿里巴巴的账户上偷盗了2000元

-- 阿里巴巴账户减少2000
update accout set money = money-2000 where name = '阿里巴巴';
-- 四十大盗账户增加2000
update accout set money = money+2000 where name = '四十大盗';

假如在执行以上第一句SQL时，出现网络错误，或是数据库挂掉了，阿里巴巴的账户会减少2000，但是四十大盗的账户上就没有了增加的金额。这是比较严重的错误。此时，数据就会出现“不上不下”的中间状态，非常明显的bug！！！

引入事务就是为了避免上述的问题。

解决方案：使用事务来控制，保证以上两句SQL要么全部执行成功，要么全部执行失败。

事务的本质就是把多个sql语句给打包成一个整体，要么全部执行成功，要么全部执行失败。而不会出现"执行一半"这样的中间状态。

3.2 事务的概念

事务指逻辑上的一组操作，组成这组操作的各个单元，要么全部成功，要么全部失败。

在不同的环境中，都可以有事务。对应在数据库中，就是数据库事务。

把多个sql语句给打包成一个整体：称为原子性(atom)；过去的人们认为原子是事物能够分割的最小单位。现在并非原子是最小分割单位。
全部执行失败：不是真的没执行，而是"看起来好像没执行一样"，其实是执行了，执行一半出错了，出错之后选择了恢复现场，把数据还原成未执行之前的状态了。
这个恢复数据的操作，称为“回滚" (rollback)

【案例】

单独执行的每个sql都是自成一个体系，此时这些sql之间是没有原子性的。
如果把这俩操作作为一个事务，当第一个 sql执行完之后，数据库崩溃。当下次数据库重新启动完成之后，就会自动的把上次修改一半的数据给进行还原(把1号用户-500再加回来就行了)。

3.3 使用事务

开启事务：start transaction;
执行多条SQL语句。这个过程中某个环节出现问题，例如程序崩溃/数据库崩溃/机器断电了，就会自动触发回滚机制。
提交或主动触发回滚：commit/rollback;

commit; 提交事物，意思是下面没有sql语句了，该事务结束了。事务结束的标记。
rollback 是主动触发回滚。出错有很多情况，崩溃/断电只是其中一种(会自发触发回滚)，有时候需要主动通过代码方式判断当前是否需要回滚。所以rollback一般是要搭配一些条件判断逻辑来使用的。sql里也能支持条件,循环,变量,函数...，但是日常开发一般不会这么写，更多的是搭配其他的编程语言。例如使用java操作数据库，在java中主动判定某个结果是否符合要求，如果不符合要求进行主动回滚。
说明：rollback即是全部失败，commit即是全部成功。

回滚是怎么做到，把数据还原成未执行的状态?

依据日志中的记录，进行回滚操作。 例如日志里记录的操作是插入，回滚根据记录就删除。记录的操作是删除，回滚根据记录就插入。如果记录的操作是修改，回滚根据记录就改回去。

数据库里专门有个用来记录事务关键操作的日志(正因为如此，使用事务的时候，执行sql的开销是更大的，效率是更低)。日志：是打印出来的内容，存放在文件里。
日志是存放在文件中的，所以即使是主机掉电，也不影响(回滚用的日志已经在文件中了)。后续一旦重新启动主机，mysql也重新启动，就会发现回滚日志中有一些需要进行回滚的操作。于是就可以完成这里的回滚了。

3.4 事务四大关键特性

数据库的事务，有四个关键的特性:

原子性：把多个sql语句给打包成一个整体，要么全部执行成功，要么全部执行失败 ——最核心的特性
一致性：事务执行前后，数据要合理。(很多时候是要靠数据库的约束以及一系列的检查机制来完成的)

3. 持久性：事务修改的内容是写到硬盘上持久保存的。重启服务器，数据仍然是存在的。

4. 隔离性：是为了解决"并发"执行多个事务，引起的问题。

并发：

一个餐馆(服务器)，同一时刻能给多个顾客(客户端)提供服务，这些顾客可能是一个接一个来的，也可能是一起来了一波顾客。
此时，服务器同时处理多个客户端的请求，就称为"并发"(齐头并进的感觉)。
同时能处理客户端请求越多，并发程度越高，整体的效率就越高。

数据库也是服务器，一定会存在多个客户端给服务器提交事务的情况。为了提高效率，就会提高并发程度，但在数据库中提高并发程度之后，可能存在一些问题，会导致数据出现一些“错误”的情况。
隔离级别，就是在"数据正确"和"效率"之间做权衡。往往提升了效率，就会牺牲正确性；提升了正确性，就会牺牲效率。
事务的隔离性，存在的意义就是为了在数据库并发处理事务的时候不会有问题，即使有问题，问题也不会太大。

4. 事务隔离性解决并发问题

下面介绍，数据库中并发执行事务可能产生的问题，以及数据库的隔离性是怎样解决的。

4.1 脏读问题

问题描述：

在我写代码的过程中，同学在我身后经过，他瞄了一眼我的屏幕，看到了我的代码中写了一些内容，比如他看到了，我的代码里有一个class Student，有一些属性，id, name，gender... 然后他就走了，很可能他走了之后，我的代码又改了。
即一个事务A正在对数据进行修改的过程中，还没提交之前；另外一个事务B，对同一个数据进行了读取，此时B的读操作就称为“脏读"，读到的数据也称为"脏数据"。
脏的意思，是"无效"，而不是埋汰。为啥说无效？很可能，A回头又把数据给修改了。即另一个事务读取到的数据不一定是最终的结果，可能是无效数据。

解决方法：写的时候不能读，写操作加锁。

为了解决脏读问题，mysql 引入"写操作加锁"这样的机制。
即我和同学们商量好，我写代码的过程中你别来看，等我改完提交到码云上，你再通过我的码云来看，写的时候不能看(给写操作加锁)，写完了才能看。
当我写的时候同学没法读，意味着我的“写操作"和同学的"读操作"不能并发了（不同同时执行了）
这个给写加锁的操作，就降低了并发程度（降低了效率），提高了隔离性（提高了数据的准确性）

4.2 不可重复读

问题描述：

还是我写代码，同学想看，约定好我写的时候不许看，等我提交了，再通过码云来看。当前约定好了写加锁。
我写代码提交了版本1，此时就有同学开始读这个代码了；于是我又打开代码继续修改优化代码，然后又提交版本2。这个同学开始读的过程中，读到的是版本1的代码，读着读着我提交了版本2，此时这个同学读的代码，刷的一下变样了。这个问题，叫做“不可重复读"。
事务1已经提交了数据，此时事务2开始去读取数据，在读取过程中，事务3修改了数据提交了新的数据，此时意味着同一个事务2之内，多次读数据，读出来的结果是不相同的（预期是一个事务中，多次读取结果得一样）就叫做"不可重复读"。即同一个事务中第二次读取的结果不能复现第一次的结果。

解决方法：读的时候不能写，读操作加锁。

解决不可重复读问题，需要给 读操作加锁。
同学发现了这个问题之后，知道了是在他读的过程中，我又改代码了，于是来找我和我约定，同学读代码的时候，我也不能修改。
脏读问题约定的是，我修改的时侯，提交之前，同学不要读，是给写加锁。而不可重复读问题是在写加锁的基础上约定，同学读的时候，我不能修改，就是给读加锁。
通过这个读加锁，又进一步的降低了事务的并发处理能力（处理效率也降低），提高了事务的隔离性（数据的准确性又提高了）

4.3 幻读

问题描述：

当前已经约定了读加锁和写加锁，解决了不可重复读和脏读问题。
由于约定了读加锁，同学读的时候我不能修改代码，我在这干的等着光摸鱼不干活有点难受，所以我想了办法，同学读Student.java文件，我就创建一个Teacher.java文件，写这个代码；这样的情况，大多数情况下都没事，少数情况下，个别同学发现了，读代码读着突然冒出个Teacher.java，有的同学就觉得接受不了。
在读加锁和写加锁的前提下，一个事务A两次读取同一个数据，发现读取的数据值是一样的，但是结果集不一样（Student.java 代码内容不变，但是第一次看到的是只有Student.java这个文件，第二次看到的是Student,java和Teacher.java ..）这种就称为"幻读"。

解决方法：串行化执行事务。

数据库使用"串行化"这样的方式来解决幻读，彻底放弃并发处理事务，一个接一个的串行的处理事务，这样做并发程度是最低的(没并发了，效率最慢的)，隔离性是最高的(准确性也是最高的)
相当于是同学们要求，在他们读代码的时候，我不要摸电脑，必须强制摸鱼！！！

4.4 隔离级别

上述三个问题，就是并发处理事务的三个典型问题。

mysql提供了4种隔离级别，对应上述三个问题。针对隔离程度进行设置，来应付不同的需求场景情况：

read uncommitted (读未提交) 没有进行任何锁限制，并发程度最高(效率最高)，隔离性最低(准确性最低)
read committed (读已提交) 给写加锁了，并发程度降低(速度减低了)，隔离性提高了(准确性提高了)。
repeatable read (可重复读) 给写和读都加锁，并发程度又降低(速度减低了)，隔离性又提高了(准确性提高了)。
serializable (串行化) 严格的按照串行的方式，一个一个的执行事务，并发程度最低(没有并发，速度最低)，隔离性最高(准确性最高)。

上述隔离级别是mysql内置的机制，可以直接在mysql配置文件中，修改数据库的隔离级别，来设置当前mysql 工作在哪种状态下。

这几个隔离级别，如何选择？

根据不同的实际需求/业务场景了，修改配置文件，设置不同的隔离级别。
例如：转账的时候，一分钱都不能差，哪怕慢点，也得转对。准确性要拉满，效率不关键。
例如：短视频点赞，一个视频有多少赞，要求快，赞的数量差个十个八个都没事。追求的是效率，准确性就不关键。
如果没有通过修改mysql配置文件，手动的去设置隔离级别；默认的隔离级别是repeatable read (可重复读)。一般默认的隔离级别，就能很好的应对开发中的绝大部分场景了。

好啦Y(^o^)Y，本节内容到此就结束了。下一篇内容一定会火速更新！！！

后续还会持续更新MySQL方面的内容，还请大家多多关注本博主，第一时间获取新鲜的知识。

如果觉得文章不错，别忘了一键三连哟！