【MySQL】索引事务

一、索引

概念

作用

使用场景

使用

查看索引

创建索引

删除索引

背后的数据结构

二、事务

为什么使用事务

事务的概念

使用

开启事务

执行多条 SQL 语句

回滚或提交：rollback/commit;

事务的基本特性

原子性

一致性

持久性

隔离性

脏读

不可重复读

幻读

隔离级别

read uncommitted 读未提交

read committed 读已提交

repeatable read 可重复读

serializable 串行化

一、索引

概念

索引是一种特殊的文件，包含着对数据表里所有记录的引用指针。可以对表中的一列或多列创建索引，并指定索引的类型，各类索引有各自的数据结构实现。

📕类似于书的目录

作用

所谓的 "索引" 就相当于是在数据库中，构建一个特殊的 "目录"（在硬盘上的一系列特定的数据结构），通过这样的数据结构，加快查询的速度，尽可能避免针对表数据的遍历操作。

🔅数据库中的表、数据、索引之间的关系，类似于书架上的图书、书籍内容和书籍目录的关系。
🔅索引所起的作用类似书籍目录，可用于快速定位、检索数据。
🔅索引对于提高数据库的性能有很大的帮助。

⏩加快查询速度

使用场景

引入索引，是能够提高查询的速度，也会付出一些代价
1️⃣引入索引，需要消耗额外的存储空间。
2️⃣引入索引之后，确实能提高查询的效率，但是可能会影响到增删改的效率。
（有的时候增删改会更慢-增删改的时候需要同步的更新维护索引，有的时候会更快，有的时候，没啥变化）

要考虑对数据库表的某列或某几列创建索引，需要考虑以下几点：
⚫️数据量较大，且经常对这些列进行条件查询。
⚫️该数据库表的插入操作，及对这些列的修改操作频率较低。
⚫️索引会占用额外的磁盘空间。
满足以上条件时，考虑对表中的这些字段创建索引，以提高查询效率。
反之，如果非条件查询列，或经常做插入、修改操作，或磁盘空间不足时，不考虑创建索引。

索引，有利有弊，但是即使如此，实际开发中，还是比较鼓励使用索引的
1️⃣硬盘往往不是主要矛盾。
2️⃣对于增删改也不一定都是负面影响，也可能会触发一些正面效果。另一方面，很多业务场景，查询的频率比增删改要高很多。

使用

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

查看索引

show index from 表名;

👁‍🗨案例：查看学生表已有的索引

show index from student;

上述是针对 id 列创建索引，接下来查询的时候以 id 为条件的时候，才能够使索引生效，才能够提升查询速度。同样的，如果是针对 name 列创建索引，接下来查询应以 name 为条件，才能使索引生效。

一个表也可以允许有多个索引，就像词典有

拼音目录

部首目录

笔画目录

drop table student;

create table class(classId int primary key,className varchar(20));

show index from student;

创建索引

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

create index 索引名 on 表名(列名);

👁‍🗨案例：创建班级表中，name 字段的索引

create index name_index on student(name);

show index from student;

🛑创建索引，也是一个 "危险操作"，如果是针对空表，或者表中的数据比较少（几干，几万…）创建索引，就谈不上危险不危险，一旦表的数据量比较大，干万级别，此时创建索引操作，就可能会触发大量的硬盘 IO，直接把机器就搞的卡死住了。所以在最初建表的时候都要有哪些索引，提前规划好，创建好。

删除索引

drop index 索引名 on 表名;

☄️只能删除自己创建的索引，不能删除自动生成的

👁‍🗨案例：删除班级表中 name 字段的索引

drop index name_index on student;

背后的数据结构

所谓的 "构建索引" 其实就是引入一些数据结构，对数据进行存储，从而提高查找的速度

B + 树是专门为数据库索引量身定做的一种特殊的数据结构

二、事务

为什么使用事务

事务是用来解决一类特定场景的问题的，有些场景中，完成某个操作，需要多个 SQL 配合完成的

例如下面的转账过程

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，但是四十大盗的账户上就没有了增加的金额。

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

事务的概念

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

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

即把多个要执行的 SQL，打包成一个 "整体"，这个 "整体" 在执行过程中就能够做到要么整个都执行完，要么就一个都不执行。就可以避免出现上述转账一半的中间状态。

此处的 "一个都不执行" 不是这些 SQL 真的没执行，而是执行一半，发现出错的时候数据库会自动进行 "还原操作"，相当于把前面执行过的 SQL 给进行 "撤销"，最终的效果就看起来好像是一个都没执行这样的效果。这样的机制，称为 "回滚"(rollback)。同时，也把事务支持的上述的 "特性" 称为 "原子性"（过去人们以为 "原子" 就是不可拆分的最小单位了）。类似于商家把顾客退回的货重新卖出去。

数据库如何知道，具体是怎样回滚的？如何知道，前面的SQL做出了啥样的修改呢？数据库内部存在一系列的 "日志体系"，记录到 "文件" 中，当开启事务的时候，此时每一步执行的SQL，都对数据进行了哪些修改，这些信息就会记录在案，后续如果需要回滚，就可以参考之前记录的内容，进行还原了。由于是记录在 "文件" 中，所以既可以应对 "程序崩溃"，也能应对 "主机掉电"（虽然掉电，但是回滚的日志还是存在的，此时下次主机上电，下次数据库启动的时候就可以根据回滚日志的内容，就进行回滚操作了）。

问题来了，drop database这样的操作能回滚回来吗？不能的。回滚操作，只是针对 "事务" 来说的，开启事务之后，就会记录回滚日志，事务执行过程中，出现问题，自动触发回滚。一方面，drop database这样的操作不能放到事务中去执行，另一方面，这个操作，也不算执行出错，算是 "正确执行了SQL"，开启事务之后，一个事务内，虽然是执行多个 SQL，执行的内容也不能太多。

🍀事务最核心的特性，就是原子性，能够解决的问题，就是批量执行 SQL 的问题
🍀除了转账之外，还有新生登记（可能需要往学生表/班级表同时插入数据）
🍀电商网站上下单（可能需要改商品表的库存数据/新增订单数据）

使用

开启事务

start transaction;

执行多条 SQL 语句

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

回滚或提交：rollback/commit;

commit;

说明：rollback 即是全部失败，commit 即是全部成功。

事务的基本特性

原子性

最重要的特性

一致性

描述的是事务执行前和执行后，数据库中的数据，都是 "合法状态"，不会出现非法的临时结果的状态，类似于对账的过程

持久性

事务执行完毕之后，就会修改硬盘上的数据，事务都是会持久生效的

隔离性

描述了多个事务并发执行的时候，相互之间产生的影响是怎样的，MySQL 是一个 "客户端-服务器" 结构的程序，一个服务器，通常会给多个客户端同时提供服务因此，很可能，这多个客户端，就同时给这个服务器提交事务来执行，与之相对，服务器就需要同时执行这多个事务，此时就是 "并发" 执行，此时，如果这些同时执行的事务，恰好也是针对同一个表进行一些增删改查，此时就可能会在并发执行事务的过程中涉及三个问题。

脏读

有两个事务 A 和 B 并发执行，其中事务 A 在针对某个表的数据进行修改，A 执行过程中，B 也去读取这个表的数据，当 B 读完之后，A 把表里的数据又改成别的。这就导致，B 读到的数据，就不是最终的 "正确数据"，而是读到了临时性的，"脏数据"（往往指的是 "数据过期，过时了"，错误的数据）。

⚠️解决方案：在修改的时候给写操作 “加锁”，设置成不可读。

不可重复读

此时，有三个事务，A B C。首先，事务 A 执行一个修改操作，A 执行完毕的时候，提交数据。
接下来事务 B 执行，事务 B 读取刚才 A 提交的数据，在 B 读取的过程中，又来了一个事务 C，C又对刚才 A 修改的数据再次做出了修改，此时对于B来说，后续再读取这个数据，读到的结果就和第一次读到的结果是不一样的，这个过程就叫做 "不可重复读"，体现的是事务 B，在一个事务里多次读取的结果不一样的。如果是有多个事务，每个事务读到的数据不一样，这种情况认为是正常的。

⚠️解决方案：给读操作 “加锁”，一个事务在读取数据的过程中，其他的事务不能修改它正在读的数据