MySQL秘密武器：索引与事务

ok，今天来分享下MySQL中的索引与事务。

当我们进行查询的时候，数据咻的一下就查询出来，速度很快噢。

那么这里呢，就有了索引的功劳了。

所以，先来介绍下索引是什么？

索引

索引是数据库中的一种数据结构。但我们可以理解为像是一本书中的目录，而我们更早接触到类似的，比如我们学习的数组的下标。

由前面的引入，显然，索引的引入是为了加快查询速度的。

一枚硬币既有反面也有正面。显然这个索引也是带来一些缺点（代价）

1.引入索引会消耗一些存储空间

2.索引的引入，确实能提高查询速度，但不总是能提高增删改的速度。

体现在：加快、拖慢、没什么变化

加快：比如删除操作：delete from student where id=5；这里就涉及了查询。

拖慢：比如进行增删改的时候，需要同步更新维护索引。

所以，这么看来索引可谓是有利也有弊。所以大家要辩证的去使用它。

那么讲到这，索引如何去使用呢？

索引使用

1.查看索引

语法：show index from 表名

这里举个例子

这里有两张表：cla、student。

所以我查询两张表的索引：

这里cla查询出来是空的，student是存在一个索引的

为什么呢？

回到展示表结构那个图片。

可以发现，cla中那key列中，没有任何信息。

所以查询出来的时候就没有索引信息。

所以就此得出了，primary key是会自带索引的。

同时也值得注意的是，这个primary key索引是不用我们手动添加的，指定主键后就会自动添加。

那么就只有这一个？

当然不是

还有unique 和 foreign key

unique

foreign key

还有一些注意的点，你对那个列进行索引创建，那么查询的时候以这个列为条件，查询就快。

同时一张表中可以存在多个索引，但是主键不能存在多个噢。

2.创建索引。

语法：create index 索引名 on 表名（列名）

还是举个例子

创建一个班级表，为id列创建索引，索引名为index_id

这个操作具有一定危险性，

当前表的数据量好说，一旦涉及到千万级别的表数据，那么这个操作就会触发大量的硬盘IO，可能导致机器垮掉。

因为，索引创建中，有一步就是要进行全表扫描，搜集所有列的值并构建索引机构，这样是产生磁盘的大量读写操作。

所以，创建索引的过程，一般也是事先商量好的，或者规划好的。

3.删除索引

语法：drop index 索引名 on 表名

举个例子

刚刚为class创建了个index_id索引，现在删除掉。

但值得注意的是，像是primary key 和 foreign key这些创建之后，数据库自动生成的不能删除。

那么讲到这里，索引一些操作讲完了。

接下来就要讲讲另外一个了，

前面说到索引是一种数据库中的数据结构。

那么这种数据结构是什么呢？

索引背后的数据结构

是我们接触数据结构时的那些？

比如顺序表、链表、栈、队列？

还是二叉树搜索树、哈希表？

顺序表、链表、栈、队列这些是可以pass掉了，毕竟有些能做其一，不能做其二，要么就是插入耗资源，要么就是查找耗资源。

那么二叉搜索树和哈希表呢？

其实也不然，二叉搜索树，重点在二叉上，当我们插入很多数据时，树的高度很高了，再去插入，对硬盘也是一个不小的挑战。

哈希表呢？

查询速度是很快，但不能进行模糊查询，进行的是精确性的查找。

那么到底是什么适合呢？

答案揭晓：

B+树

当然介绍这个之前，先来浅浅介绍下B树

B树是一棵n叉搜索树，每个节点都能分出多个子树。

这么一说，发现，这样就是可以降低树的高度咯。

那么举一个实例图咯

由图可以得知，一层中保存了n个key节点，可以分出n+1个子树来。

虽然，这里插入还是需要多次比较，才能走下一个。

但是比二叉搜索树优势很大，起码高度降低不少，且一层一层节点中的数据全部一次硬盘IO就行，不在需要多次IO了。

那么B+树呢？

B+树是B树的进一步优化的数据结构来的，同时它也是一个n叉搜索树。

还是给个图片看看

这是一个B+树的简单示意图。

在第一层节点中16，就是整个树的最大值。

对比B树，发现是少一个区间的。

即N个key，就是有N个区间。

同时还发现了，父节点的中的最大值会下放到子区间中，作为最大值，比如第一层中的8，作为父节点，下放到左边的区间是作为最大值的。

最后，在叶子节点中，所有的值会呈现数据的全集，就像是1-16全部的集合

通过链表的形式存储下来。

同时值得注意的是，这些非叶子节点是不存储数据行，叶子节点才存储，所以也得出了，我们查询数据都是落到叶子节点进行的。

所以当我们进行范围查询的时候，这个就特别有用。

ok，可以来简单总结下B+树的优势有什么

优势：

1.N叉搜索树，高度较低，磁盘IO较少。

2.叶子节点是表示数据范围的全集，并用链表进行连接，非常便于进行查询

3.B+树所有的查询，最终落到叶子节点下，任何的一次查询，我们的磁盘IO次数和比较次数是不会相差太大，，所以查询开销较为稳定。

4.同时B+树中，由于非叶子节点不存储“数据行”，存储索引列的key值，叶子节点才存储“数据行”，所以占用的空间少。

ok，到这里，分享完第一个秘密武器了。

接下来到事务了。

事务

咋一听这词有点陌生呢。

这是我们不常接触的话，就有点陌生咯。

事务是什么呢？

事务是一组作为单个逻辑单元的执行的SQL语句。

简单来说，就是解决一些特定场景的问题的。

举个例子。

我们平时用的较多的转账。

比如有两个这样的账户：

1：1000

2：500

那么现在1对2进行转账500元

一般的操作流程就是先对1账户进行减去500元

再对2账户进行增加500元；

不出意外的，一切都顺利成章，那么账户1就是有500，账户2就有1000.

但意外总是无处不在的，万一执行第一个操作之后，突然出现程序崩溃、主机崩溃啥的，没能执行第二个语句，那么数据库内容就会出错。那客户不得更银行急眼。

所以为了解决这个问题，引入了事务。

把这些语句打包成一个整体，这个整体执行中，要么全部执行完，要不都不执行。

但值得注意的是，都不执行这里不是说一个sql语句都不执行。

而是执行到一半的时候，发现错误的时候，数据库会自动进行“还原操作”，把之前执行语句给“撤销”，达到什么都没有做的效果。

这个“还原操作”在数据库中就成为回滚（rollback）。

那么数据库是如何知道，怎么回滚？怎么把之前的操作复原的呢？

这里呢归功于数据的库中强大的日志体系

这一系列的日志体系，会把我们开启事务的时候，执行的每一个sql语句，以及对数据进行哪些修改，都会记录下来。

这样当我们主机断电，程序错误且需要回滚的时候，就可以根据记录的信息，进行还原操作了。

但是我们要注意的的是，回滚只在事务中进行，还有，事务中的sql语句也是不能够太多的。

诶，上诉这里就涉及到了事务的一个特性——原子性。

那么讲到了事务的特性，那么事务是特性有什么呢？

特性

1.原子性

刚刚上面讲诉过了

2.一致性

事务执行前执行后，数据库中的数据都是“合法的状态”，不会出现非法临时结果性的状态

3.持久性 事务执行完毕后，就会修改硬盘上的数据，而且这些修改是持久生效的。

4.隔离性

这个呢，解释起来，就是说，描述多个事务并发执行的时候，相互之间产生的影响是怎样的。

诶，并发执行又是怎么样呢？

比如说，MySQL中提供的多个客户端，且每个客户端提交了多个事务给到服务端，与此同时，服务端收到多个事务需要同时执行的时候，这个时候就是并发执行。

都在执行的话，或多或少会产生一些问题的。

比如，当同时执行这些事务的时候，恰好针对一个表，且进行了一些增删改查。

那么我们可能会引入这样的问题：
1.脏读

2.不可重复度

3.幻读

那我们来一一解释下

脏读：

比如现在有两个事务A和B并发执行

其中事务A对某个表进行数据修改。与此同时，B对这个表进行读取，B读完后，A呢就把数据进行修改完成了

这样导致了B读的数据，不是A最终改为的数据，而是临时性的“脏数据”，也可以称之为“过期了”。

通俗点，当我进行对我的白月光写一篇“小作文”的时候，我的朋友偷看到了，然后并没有等我写完，就去告诉了我的白月光，可是我写到一半，发现不对，重写了再次发给白月光，那么白月光收到的信息和我朋友传达的信息就不一致了。

解决办法也挺简单的，就是约束一下，我写的时候，我的朋友不能读，等我写完提交给我的白月光了，你再来读。

不可重复读：

这里呢涉及到了三个事务了，

比如A事务执行修改操作，然后把数据提交了，然后B事务进行读取A提交的数据的时候，突然来个C事务进行把刚刚A提交的事务进行修改了，然后当B再次读取时候，就会发现，第一次读取和第二次读取，出现数据不一致。当然，这里更多指的是针对一个事务来讲，比如B事务

通俗点解释

还是那我给白月光写“小作文”的例子，这次呢，我写完了，我本人没做修改，同时我的朋友也是完完全全读取到了，然后我的朋友屁颠屁颠的去我的白月光那边再想看一次，这时候，我发现写的不好，我教我的“文豪"朋友来帮我把之前的”小作文“修改一下，然后再次发给我的”白月光“。此时当我那个朋友去到白月光那边进行读的时候，发现第一次读和第二次读，发现不一致了。

如何解决呢？

还是约定一下，当我那个朋友在我白月光那边进行读取的时候，就不能修改正在读的文章了

幻读：

比如，有一个事务A在读取数据的时候，读的过程中，另外一个事务B进行增删一些数据，此时，在A的角度上看，当进行结果集查询的时候，第二次查询出现了第一次不存在的记录。

那么如何去解决呢？

这里我们直接一些，当事务A读的时候，B事务不能进行任何操作，有点线性化那样。这样的操作称之为串行化，就是一个个排队执行完事务。

那以上三个问题和隔离性有什么关系呢？

诶，这里的MySQL隔离提供了四个级别，通过一些配置文件来设置当前服务器的隔离级别是哪个级别，从而影响到三个问题出现的情况。

那么有哪四个呢？

1.read uncommitted   读未提交

这样的情况下，一个事务是可以读取另一个事务未提交的数据，那么及其容易出现脏读、不可重复读、幻读的问题。

但此时事务并发执行的速率是最高的，执行速度最快！

2.read committed 读已提交。

这样的情况下，一个事务只能读取已经提交的数据，可能会产生不可重复读或者幻读问题。但脏读解决了。

此时，并发程度降低，速度也降低，但隔离性提高了，也就是说，事务间的相互影响较小，数据更准确些了。

3.repeatable read 可重复读。

这样的情况下，就是进行了一些写和读操作的加锁，当这个事务正在执行的时候，不能对此内容进行读和写，解决了不可重复读和脏读问题，可能会出现幻读问题。同时速度降低，并发程度进一步降低，但事务间的隔离性进一步提高！

4.串行化

这个时候，事务是在服务器上一个个的执行，就像排队一样，这时候脏读、幻读、不可重复读也解决了。此时，速度最低，并发程度也是最低的,但是隔离性是最好的，数据最准确！

当然，这里提到的一些速度和准确性是相对业务场景而言，什么时候需要快，什么时候需要准确，

都是对业务需求分析后而定夺的。

那么，这个事务和索引，就浅浅的分享到这啦~