MySQL索引

索引基本描述
索引是一个单独的、存储在磁盘上的数据库结构，它们包含着对数据表里所有记录的引用指针。使用索引用于快速找出在某个或多个列中有一特定值的行，所有MySQL列类型都可以被索引，对相关列使用索引是提高查询操作速度的最佳途径。
MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。比如我们在查字典的时候，前面都有检索的拼音和偏旁、笔画等，然后找到对应字典页码，这样然后就打开字典的页数就可以知道我们要搜索的某一个key的全部值的信息了。
创建索引时，你需要确保该索引是应用在 SQL 查询语句的条件(一般作为 WHERE 子句的条件)，而不是在select的字段中，实际上，索引也是一张“表”，该表保存了主键与索引字段，并指向实体表的记录，虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件，建立索引会占用磁盘空间的索引文件。说白了索引就是用来提高速度的，但是就需要维护索引造成资源的浪费，所以合理的创建索引是必要的。

索引分类
由于本文是基于mysql的InnoDB存储引擎，从表格我们可以看出来，InnoDB存储引擎索引只支持BTREE类型的索引，索引的类别有Primary Key，Unique，Key，FULLTEXT和SPATIAL。当然也有其他的分法，按照索引列的数量分为单列索引和组合索引。

Primary Key（聚集索引） ：InnoDB存储引擎的表会存在主键（唯一非null），如果建表的时候没有指定主键，则会使用第一非空的唯一索引作为聚集索引，否则InnoDB会自动帮你创建一个不可见的、长度为6字节的row_id用来作为聚集索引。

单列索引：单列索引即一个索引只包含单个列

组合索引：组合索引指在表的多个字段组合上创建的索引，只有在查询条件中使用了这些字段的左边字段时，索引才会被使用。使用组合索引时遵循最左前缀集合

Unique（唯一索引） ：索引列的值必须唯一，但允许有空值。若是组合索引，则列值的组合必须唯一。主键索引是一种特殊的唯一索引，不允许有空值

Key（普通索引） ：是MySQL中的基本索引类型，允许在定义索引的列中插入重复值和空值

FULLTEXT（全文索引） ：全文索引类型为FULLTEXT，在定义索引的列上支持值的全文查找，允许在这些索引列中插入重复值和空值。全文索引可以在CHAR、VARCHAR或者TEXT类型的列上创建

SPATIAL（空间索引） ：空间索引是对空间数据类型的字段建立的索引，MySQL中的空间数据类型有4种，分别是GEOMETRY、POINT、LINESTRING和POLYGON。MySQL使用SPATIAL关键字进行扩展，使得能够用于创建正规索引类似的语法创建空间索引。创建空间索引的列必须声明为NOT NULL

组合索引的遵循最左前缀原则：
所谓的组合索引就是指，由两个或以上的字段共同构成一个索引。
本文测试用例的数据表结构如下，一张简简单单的学生信息表 tb_student，仅包含四个字段（student_id、student_name、student_age、student_addr）

那比如说，我们现在的业务需求经常要通过学生的年龄（student_age）和学生的家庭住址（student_addr）来同时筛选学生，如下
`SELECT * FROM tb_student WHERE student_age = 20 AND student_addr = '北京'; 那此时我们就最好在 student_age 和 student_addr 这两个字段上同时设置索引（注意，这里不是在这两个列上各自设置一个索引），这就是联合索引，我们执行下面的 sql 语句来设置联合索引。

设置索引的方式：
ALTER TABLE 表名 ADD INDEX 索引名(列名…)
ALTER TABLE tb_student ADD INDEX test_index(student_age,student_addr);

最左前缀匹配原则

最左前缀匹配原则，是一个非常重要的原则，可以通过以下这几个特性来理解。

对于联合索引，MySQL 会一直向右匹配直到遇到范围查询（> ， < ，between，like）就停止匹配。比如 a = 3 and b = 4 and c > 5 and d = 6，如果建立的是（a,b,c,d）这种顺序的索引，那么 d 是用不到索引的，但是如果建立的是（a,b,d,c）这种顺序的索引的话，那么就没问题，而且 a，b，d 的顺序可以随意调换。 = 和 in 可以乱序，比如 a = 3 and b = 4 and c = 5 建立（a，b，c）索引可以任意顺序。如果建立的索引顺序是（a，b）那么直接采用 where b = 5 这种查询条件是无法利用到索引的，这一条最能体现最左匹配的特性。这么说还看不懂也没关系，下面会我通过四个简单的小例子来帮助你明白。

看例子之前，先要普及一下 explain 这个关键字的用法。
explain 是用来分析 SELECT 查询语句的，开发人员可以通过分析 explain 结果来优化查询语句。文章接下来将会大量使用 explain 来观察索引是否被使用到，我们先简单的看一个 explain 使用的小例子。

就用最简单的，扫描 tb_student 全表。
SELECT * FROM tb_student
我们用 explain 分析一下
EXPLAIN SELECT * FROM tb_student

注意我圈红的这仨字段，这是使用 explain 语句需要重点关注的字段

type：访问类型，要是显示 ALL ，那你可要小心了，这是全表扫描的意思，性能最差，说明你的查询有很大的优化余地，如果显示的是 index ，说明会使用索引来优化查询。关于 type 的更多解释请参考这个文章：mysql中explain的type的解释

key：具体使用的索引名，这里没有。

rows：扫描的行数。举四个小例子了，还记得我们在上面刚给 student_age 和 student_addr 设置完联合索引吗，现在我们使用 explain 分析四种 where 子句的执行情况。

一、where student_age = 10 and student_addr = '北京’
explain select * from tb_student where student_age = 10 and student_addr = '北京';
返回结果

OK,使用了索引。

二、where student_addr = ‘北京’ and student_age = 10
跟第一种情况相比只是调换了顺序。
explain select * from tb_student where student_addr = '北京' and student_age = 10;
返回结果

OK,还是正常。

三、where student_age = 10
explain select * from tb_student where student_age = 10;
返回结果

没问题

四、where student_addr = '北京’
explain select * from tb_student where student_addr = '北京';
返回结果\

睁大眼睛，这就是最左匹配原则。

最左匹配原则的成因

MySQL 建立联合索引的规则是这样的，它会首先根据联合索引中最左边的、也就是第一个字段进行排序，在第一个字段排序的基础上，再对联合索引中后面的第二个字段进行排序，依此类推。

综上，第一个字段是绝对有序的，从第二个字段开始是无序的，这就解释了为什么直接使用第二字段进行条件判断用不到索引了（从第二个字段开始，无序，无法走 B+ Tree 索引）！这也是 MySQL 在联合索引中强调最左前缀匹配原则的原因。

MySQL事务

讲完了索引接下来我们来了解一下MySQL事务

1.事务简介

在 MySQL 中只有使用了 Innodb 数据库引擎的数据库或表才支持事务。

事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。

事务用来管理 insert,update,delete 语句。

2.事务四大特征

一般来说，事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。(比如：A向B转账，不可能A扣了钱，B却没有收到)

隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和序列化（Serializable）。（比u人：A正在从一张银行卡里面取钱，在A取钱的过程中，B不能向这张银行卡打钱）

持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

3.事务提交、回滚

mysql> start transaction;#手动开启事务
mysql> insert into t_user(name) values('pp');
mysql> commit;#commit之后即可改变底层数据库数据
mysql> select * from t_user;
+----+------+
| id | name |
+----+------+
|  1 | jay  |
|  2 | man  |
|  3 | pp   |
+----+------+
3 rows in set (0.00 sec)


mysql> start transaction;
mysql> insert into t_user(name) values('yy');
mysql> rollback;
mysql> select * from t_user;
+----+------+
| id | name |
+----+------+
|  1 | jay  |
|  2 | man  |
|  3 | pp   |
+----+------+
3 rows in set (0.00 sec)

4.事务特性--隔离性

4.1 隔离性有隔离级别(4个)

（1）读未提交：read uncommitted
（2）读已提交：read committed
（3）可重复读：repeatable read
（4）序列化：serializable

隔离级别	脏读	不可重复读	幻读
Read uncommitted（读未提交）	√	√	√
Read committed（读已提交）	×	√	√
Repeatable read（可重复读）	×	×	√
Serializable（序列化）	×	×	×

4.2 读未提交

事物A和事物B，事物A未提交的数据，事物B可以读取到
这里读取到的数据叫做“脏数据”
这种隔离级别最低，这种级别一般是在理论上存在，数据库隔离级别一般都高于该级别

4.3 读已提交

事物A和事物B，事物A提交的数据，事物B才能读取到
这种隔离级别高于读未提交
换句话说，对方事物提交之后的数据，我当前事物才能读取到
这种级别可以避免“脏数据”
这种隔离级别会导致“不可重复读取”
Oracle默认隔离级别当隔离级别设置为Read committed 时，避免了脏读，但是可能会造成不可重复读。
大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。

4.4 可重复读

事务A和事务B，事务A提交之后的数据，事务B读取不到
事务B是可重复读取数据
这种隔离级别高于读已提交
换句话说，对方提交之后的数据，我还是读取不到
这种隔离级别可以避免“不可重复读取”，达到可重复读取
比如1点和2点读到数据是同一个
MySQL默认级别
虽然可以达到可重复读取，但是会导致“幻像读” 虽然Repeatable read避免了不可重复读，但还有可能出现幻读。

4.5 序列化

事务A和事务B，事务A在操作数据库时，事务B只能排队等待
这种隔离级别很少使用，吞吐量太低，用户体验差
这种级别可以避免“幻像读”，每一次读取的都是数据库中真实存在数据，事务A与事务B串行，而不并发

4.6 脏读、幻读、不可重复读

1.脏读：（读取未提交数据）

脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

2.不可重复读:（前后多次读取，数据内容不一致）

是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。（即不能读到相同的数据内容）

3.幻读:（前后多次读取，数据总量不一致）

事务在插入已经检查过不存在的记录时，惊奇的发现这些数据已经存在了，之前的检测获取到的数据如同鬼影一般。

注意：不可重复读和幻读到底有什么区别呢？

不可重复读是读取了其他事务更改的数据，针对update操作
解决：使用行级锁，锁定该行，事务A多次读取操作完成后才释放该锁，这个时候才允许其他事务更改刚才的数据。

幻读是读取了其他事务新增的数据，针对insert与delete操作
解决：使用表级锁，锁定整张表，事务A多次读取数据总量之后才释放该锁，这个时候才允许其他事务新增数据。

幻读和不可重复读都是指的一个事务范围内的操作受到其他事务的影响了。只不过幻读是重点在插入和删除，不可重复读重点在修改

5、事务实现的原理

下面我首先讲实现事务功能的三个技术，分别是日志文件(redo log 和 undo log)，锁技术以及MVCC，然后再讲事务的实现原理，包括原子性是怎么实现的，隔离型是怎么实现的等等。最后在做一个总结，希望大家能够耐心看完

redo log与undo log介绍
mysql锁技术以及MVCC基础
事务的实现原理

5.1 redo log 与 undo log介绍

5.1.1、什么是redo log ?

redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。当事务提交之后会把所有修改信息都会存到该日志中。

start transaction;
select balance from bank where name="zhangsan";
// 生成 重做日志 balance=600
update bank set balance = balance - 400; 
// 生成 重做日志 amount=400
update finance set amount = amount + 400;

5.1.2、redo log作用是什么？

mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

那么问题来了，如果还没来的同步的时候宕机或断电了怎么办？还没来得及执行上面图中红色的操作。这样会导致丢部分已提交事务的修改信息！

所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后在读取redo log恢复最新数据。

总结：redo log是用来恢复数据的，用于保障，已提交事务的持久化特性（记录了已经提交的操作）

5.1.3、什么是undo log？

undo log 叫做回滚日志，用于记录数据被修改前的信息。他正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息。undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。
还用上面那两张表

每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log。

5.1.4、undo log 有什么作用？

undo log 记录事务修改之前版本的数据信息，因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。

总结：undo log是用来回滚数据的用于保障，未提交事务的原子性

5.2 mysql锁技术以及MVCC基础

5.2.1 mysql锁技术

当有多个请求来读取表中的数据时可以不采取任何操作，但是多个请求里有读请求，又有修改请求时必须有一种措施来进行并发控制。不然很有可能会造成不一致。
读写锁
解决上述问题很简单，只需用两种锁的组合来对读写请求进行控制即可，这两种锁被称为：

共享锁(shared lock),又叫做"读锁"
读锁是可以共享的，或者说多个读请求可以共享一把锁读数据，不会造成阻塞。
排他锁(exclusive lock),又叫做"写锁"
写锁会排斥其他所有获取锁的请求，一直阻塞，直到写入完成释放锁。

总结： 通过读写锁，可以做到读读可以并行，但是不能做到写读，写写并行

5.2.2 MVCC基础

MVCC介绍
MVCC (MultiVersion Concurrency Control) 叫做多版本并发控制。一般情况下，事务性储存引擎不是只使用表锁，行加锁的处理数据，而是结合了MVCC机制，以处理更多的并发问题。Mvcc处理高并发能力最强，但系统开销比最大（较表锁、行级锁），这是最求高并发付出的代价。

InnoDB的 MVCC ，是通过在每行记录的后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存了行的过期时间，当然存储的并不是实际的时间值，而是系统版本号。

以上片段摘自《高性能Mysql》这本书对MVCC的定义。他的主要实现思想是通过数据多版本来做到读写分离。从而实现不加锁读进而做到读写并行。MVCC在mysql中的实现依赖的是undo log与read view;

undo log :undo log 中记录某行数据的多个版本的数据。
read view :用来判断当前版本数据的可见性

MVCC的实现，是通过保存数据在某个时间点的快照来实现的。也就是说，不管需要执行多长时间，每个事务看到的数据是一致的。根据事务开始的时间不同，每个事务对同一张表，同一时刻看到的数据可能是不一样的。不同存储引擎的MVCC实现是不同的，典型的有乐观（optimistic）并发控制和悲观（pessimistic）并发控制。

MySQL的索引和事务