1.索引

1.1 作用及代价

我们在看书时，为了提高查阅的效率，引入了目录；索引的作用，就与目录作用相同，同样是为了提高查询的效率。

有得必有失，索引在提高查询效率的同时，也做出了一些代价。

1.消耗了更多的空间

2.虽然提高了查询的效率，但是降低了插入、删除、修改的效率（例如在进行插入数据时，又需要重新调整索引，就会降低一定的效率）

但在大多情况下，查询的频率要远大于插入、删除、修改的频率，所以索引还是经常使用的。

1.2 使用

在创建主键约束(primary key)、唯一约束(unique)、外键约束(foreign key)时，会自动创建对应列的索引。

查看索引

show index from 表名;

创建索引

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

create index 索引名 on 表名(字段名);

删除索引

drop index 索引名 on 表名;

1.3 背后的数据结构

相信在认真看过博主的【数据结构专栏】后,各位小主一定对数据结构有一定的了解了。我们知道的可以提高搜索效率的数据结构有二叉搜索树和哈希表，但是这两种数据结构都不适合于做为数据库的索引。

哈希表：虽然查询效率可以达到O(1)，但是只能查询值相等的情况，在 > < between and等比较大小的方式进行查询时就不适用了。

二叉搜索树：在最坏的情况下（单支树）时间复杂度为O(N)，最好情况为O(log₂N),如果在数据库的数据较多时，搜索树的高度将会非常高，也不适合。

所以聪明的程序猿就想出了B+树这种数据结构，专门服务于数据库的索引，在了解B+树之前，我们来先了解B

树，然后再进一步了解B+树。

1.3.1 B树

B树其实就是一个N叉搜索树，每个节点上最多包含N-1个值，N-1个值可以把区间划分成N份，通过这样分成N个叉，就使得由原来的二叉搜索树的高度降低了很多。

具体结构见下图：

1.3.2 B+树

1.B+树每个节点的N个值最多可以分N个区间，而B树每个节点的N-1个值最多可以分N个区间。

2.B树中值不能重复出现，但B+树中值是可能重复出现的。（父元素的值会在子元素中以最大值/最小值的形式出现）

3.在叶子节点处，B+树会把所有的叶子节点以链表的形式首尾相连，这样的结构将会非常便于查找。

4.因为B+树的叶子节点是全集数据，所以在非叶子节点，只需要保存索引即可（只存id），这样非叶子节点占用的空间将会非常小，就可以在内存中缓存；只在叶子节点才存储具体data信息。

2.事务

2.1 为什么使用事物？（核心特性）

有这样一个场景：在张三给李四转账时，需要先将钱从张三账户中转出，再转入李四账户中，完成这样的功能需要两条sql语句才能完成（如下图），但若在完成第一条sql语句后数据库出现了问题，无法继续执行第二条语句时，便会出现平白无故减少500元的问题。

为了解决上述问题，必须保证两条SQL语句要么都执行，要么一条也不执行。这就是事物的原子性，即逻辑上的一组操作，组成这组操作的各个单元，要么全部成功，要么全部失败。

2.2 使用

（1）开启事务：start transaction;

（2）执行多条SQL语句

（3）回滚或提交：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;

2.3 事物的其他特性

事物共有四大特性，在2.1中已经介绍了事物的原子性，这是事物最核心的特性，除了原子性外，还有另外三个特性。

2.4 事物隔离（重点特性）

2.4.1 脏读、不可重复读与幻读

脏读：

一个事务A在修改数据，提交之前，另一个事务B读取了数据，此时A在B读完后又进行了修改，那么事务B所读取到的数据就是“无效的数据”，这就叫做脏读

我们引入这样的一个场景，来更好的解释这些问题。

小明正在宿舍敲老师布置的代码练习题【修改数据的事务】，这时候小赖悄悄的在后边看小明写的代码【读取数据的事务】，小赖看完以后，就去自己的电脑上敲了，这时候小明发现了一些问题，又对代码进行了修改。

此时小赖所读取到的数据就是一个脏数据【脏读问题】，读到的数据只是一个临时数据，并不代表最终结果。

为了解决脏读问题，我们需要让在提交操作之前，不能读取数据（相当于是对写操作加锁）。

不可重复读：

在一个事务A中，事务B多次读取同一个数据，得到的结果不同（在读的过程中被人修改了）

小明和小赖约定好，小明会在他写完他的代码练习后，将代码上传到GitHub上，让小赖看他的GitHub。

于是小明在完成代码练习后上传至GitHub，然而在小赖在GitHub上看小明的代码时，小明又有了新的想法，于是对代码又进行了修改并再次提交。这时小赖正在读着的代码发生了改变。

为了解决不可重复读的问题，需要使用读加锁来解决。

也就是小明和小赖约定好，在小明写的时候小赖不去看，同时在小赖读的时候，小明也不去改。

幻读：

事务B两次读取虽然关心的数据相同，但是结果集变了

（可能原来只有一个.java文件，再下次读的时候就是两个.java文件了），这种情况被称为“幻读”，可以视为是“不可重复读”的特殊情况。

小明对小赖说，你先看A题的代码，我去改改B题，这样并不会影响你正在看的数据，但是小赖在小明改代码前后，虽然他关心的A题代码并没有发生变动，但是结果集发生了变化。

为了解决幻读问题，需要执行“串行化”

小明必须和小赖约定好，小明在写代码的时候，小赖不看；小赖在读取代码的时候，小明必须关上电脑，代码一点也不改动。

2.4.2 事务隔离级别

上述脏读、不可重复读、幻读的问题都是在并发执行事务中可能带来的影响，但是产生这些影响，并不一定就是bug。

是不是bug，需要根据实际需求来决定。我们需要看实际需求中对于数据的精确度要求。

如果需求对于数据精确度要求不高（比如抖音视频的点赞数，B站的投币数），那么上述问题就不是bug，因此就可以让并发程度高一些，隔离性低一些，提高效率。

如果需求对于数据精确度要求很高（比如银行转账），那上述的问题就是bug，因此就得让并发程度低一些，隔离性高一些，提高准确度。

为了满足不同的需求，MySQL提供了“隔离级别”选项，给了我们四个等级，让我们根据实际需求来选择不同的等级，以平衡效率和准确性。

下述表格中x代表可能存在的问题，√代表能够解决的问题。