深入理解MySQL索引及事务
✏️✏️✏️今天给各位带来的是关于数据库索引以及事务方面的基础知识
清风的CSDN博客
希望我的文章能对你有所帮助，有不足的地方还请各位看官多多指教，大家一起学习交流！
动动你们发财的小手，点点关注点点赞！在此谢过啦！哈哈哈！
目录
一、索引
1.1 概念
1.2 作用
1.3 使用场景
1.4 使用
1.4.1 创建索引
1.4.2 查看索引
1.4.3 删除索引
二、事务
2.1 为什么使用事务
2.2 事务的概念
2.3 使用
2.4 事务的特性
2.4.1 典型bug1-脏读问题
2.4.2 典型bug2-不可重复读问题
2.4.3 典型bug3-幻读问题
2.4.4 事务的隔离级别
一、索引
1.1 概念
1.2 作用
- 数据库中的表、数据、索引之间的关系，类似于书架上的图书、书籍内容和书籍目录的关系。
- 索引所起的作用类似书籍目录，可用于快速定位、检索数据。
- 索引对于提高数据库的性能有很大的帮助
1.3 使用场景
- 数据量较大，且经常对这些列进行条件查询。
- 该数据库表的插入操作，及对这些列的修改操作频率较低。
- 索引会占用额外的磁盘空间。
满足以上条件时，考虑对表中的这些字段创建索引，以提高查询效率。反之，如果非条件查询列，或经常做插入、修改操作，或磁盘空间不足时，不考虑创建索引。
1.4 使用
create table student(id int, name varchar(20));
1.4.1 创建索引
对于非主键、非唯一约束、非外键的字段，可以创建普通索引 ：
语法：
create index 索引名 on 表名(字段名);例如对学生表中的id创建索引：
create index id_index on student(id);1.4.2 查看索引
语法：
show index from 表名;例如查看学生表中的索引：
show index from student;
可以看到我们给id创建的索引。
1.4.3 删除索引
语法：
drop index 索引名 on 表名;例如删除学生表中的索引：
drop index id_index from student;二、事务
2.1 为什么使用事务
准备测试表：
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
update accout set money=money-2000 where name = '阿里巴巴';
-- 四十大盗账户增加2000
update accout set money=money+2000 where name = '四十大盗';
2.2 事务的概念
2.3 使用
- 开启事务：start transaction;
- 执行多条SQL语句
- 回滚或提交：rollback/commit;
说明：rollback即是全部失败，commit即是全部成功。
start transaction;
-- 阿里巴巴账户减少2000
update accout set money=money-2000 where name = '阿里巴巴';
-- 四十大盗账户增加2000
update accout set money=money+2000 where name = '四十大盗';
commit;回滚操作，事务的原子性，本质上是依托于回滚机制的。数据库出错，事务执行失败，是怎么恢复回去的呢？是因为数据库对于事务这里有特殊的机制(undo log + redo log),通过日志写到文件里，记录之前的数据。等到数据库重启之后，读取之前的日志，检查是否有执行失败的事务，如果有，就会把这前面的操作进行回滚。
2.4 事务的特性
- 原子性：通过事务，把多个操作打包到一起。（事务最重要的特性）。
- 一致性：相当于原子性的延申，当数据库出错，不会产生像上述这种“钱凭空消失”的不科学情况。
- 持久性：事务任何的修改，都是持久化(写入硬盘)的，无论是重启程序还是重启主机，修改等都不会丢失数据。(数据库本身就是为了持久化存储)。
- 隔离性：多个事务并发执行的时候，可能会带来一些问题。通过隔离性来对这里的问题进行权衡，看是希望数据尽量准确，还是速度尽量快。
什么是并发？如果多个客户端，同时给数据库服务器发起事务请求，这个时候就叫做“并发执行事务”。如果是多个事务修改不同的表，问题不大。但是如果是修改相同的表，就可能会产生一些bug。
2.4.1 典型bug1-脏读问题
假设场景：我在写博客，跟前有同学在看我在写什么内容。但是他看了一会就走了。他走了之后，我把博客内容又改了，真正我的写完博客发出的时候，他就会发现，他之前看到的内容和现在的内容不一样。
当前有两个事务1，2，事务1修改了某个数据，但是事务还没有提交(提交的意思就是告诉数据库服务器，完毕)。而事务2读取了一个数据，此时事务2读取到的数据，很可能是一个脏的数据。因为事务1后续可能还要再次修改这个数据。
解决脏读问题，核心思路：降低事务的并发程度，给写操作加锁，意味着事务1在释放锁之前，事务2是不能访问的。
2.4.2 典型bug2-不可重复读问题
假设场景：我写完博客了，同学们开始读，这个时候我又把博客内容改了一下。此时同学们就会发现，代码突然就变了。
不可重复读，有点像脏读。但是这是“写操作”前提下导致的问题。虽然写加锁了，但是可以分多个事务，多次提交的方式来修改数据。
当前有事务1，2，其中事务1先修改数据(写加锁)，此时事务2想读数据，就需要等事务1提交完成。等到事务1提交之后，事务2开始读数据(事务2可能会多次读数据)。
又来了一个事务3，事务3又修改了上述数据，导致事务2在读的过程中，两次读到的结果不同。
解决不可重复读问题：给读操作加锁(读的时候不能写)。
2.4.3 典型bug3-幻读问题
假设场景：约定我在写博客的时候，同学们不能看。同学们读博客的时候，我也不能修改。但是，同学们在读A博客的时候，我写B博客并发出。此时，A博客的内容没变，但是他们发现博客列表变了，最开始只有A博客，现在变成AB了。
当前有事务1，2，事务1修改数据，提交。事务2开始读数据，此时有事务3，新增了一个其他的数据，此时事务2就可能出现，两次读取的“结果集”不同。
解决幻读问题：串行化，不再进行任何并发了，每个事务都是串行执行的。
2.4.4 事务的隔离级别
- 上述的三个问题，需要看实际的场景，看当前场景更关注数据的准确性，还是更关注效率。
- MySQL在配置中，提供了“隔离级别”这样的选项，我们可以根据需要，调整隔离级别，适应不同的情况。
- read uncommitted 读的时候，写操作未提交。并行程度是最高的，隔离程度是最低的。效率是最高的，数据是最不靠谱的。此时可能出现脏读+不可重复读+幻读。
- read committed 读的时候，写操作已经提交，相当于给写操作加锁，并行程度降低了，隔离程度提高了，效率会降低一些。此时可能会出现不可重复读+幻读。
- repeatable read 相当于给读操作和写操作都加锁，并行程度又降低了，隔离程度提高了，效率又降低了，数据又更靠谱了，此时可能出现幻读。
- serializable 串行化，让所有的事务串行执行，隔离程度最高，效率最低，数据最靠谱。
✨好啦，今天的分享就到这里！
希望各位看官读完文章后，能够有所提升。
✨创作不易，还希望各位大佬支持一下！
点赞，你的认可是我创作的动力！
⭐收藏，你的青睐是我努力的方向！
✏️评论：你的意见是我进步的财富！
