mysql
[事务，隔离级别，存储引擎，索引等]
事务
什么是事务
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。
事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。
事务的ACID
事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持久性（ Durability ）。这四个特性简称为 ACID 特性。
-
原子性。事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
-
一致性。事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
-
隔离性。一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
-
持久性。指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。
隔离级别
SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。
四种隔离级别
-
Read Uncommitted（读取未提交内容）
在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
-
Read Committed（读取提交内容）
这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。
-
Repeatable Read（可重读）
这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。
-
Serializable（可串行化）
这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。
脏读，不可重复读，幻读
-
脏读(Drity Read)
某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 -
不可重复读(Non-repeatable read)
在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。 -
幻读(Phantom Read)
在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。
这四种隔离级别，分别有可能产生问题如下所示：
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| Read Uncommitted | √ | √ | √ |
| Read Committed(RC) | × | √ | √ |
| Repeatable Read(RR) | × | × | √ |
| Serializable | × | × | × |
MVCC（多版本并发控制）
mysql的innodb采用的是行锁，而且采用了多版本并发控制来提高读操作的性能。
其实就是在每一行记录的后面增加两个隐藏列，记录创建版本号和删除版本号，
而每一个事务在启动的时候，都有一个唯一的递增的版本号。
举个栗子：
- Insert
比如插入一条记录, 事务id是1 ，那么记录如下,记录的创建版本号就是事务版本号。
insert into table values (1, ‘test’);
| id（主键） | name（name） | create version（创建版本号） | delete version（删除版本号） |
|---|---|---|---|
| 1 | test | 1 |
- Update
采用的是先标记旧的那行记录为已删除，并且删除版本号是事务版本号，然后插入一行新的记录的方式。
针对上面那行记录，事务Id为2 要把name字段更新。
update table set name= ‘new_value’ where id=1;
| id（主键） | name（name） | create version（创建版本号） | delete version（删除版本号） |
|---|---|---|---|
| 1 | test | 1 | 2 |
| 1 | new_value | 2 |
- Delete
就把事务版本号作为删除版本号。
delete from table where id=1;
| id（主键） | name（name） | create version（创建版本号） | delete version（删除版本号） |
|---|---|---|---|
| 1 | new_value | 2 | 3 |
-
Select
查询时要符合以下两个条件的记录才能被事务查询出来：1) 删除版本号大于当前事务版本号，就是说删除操作是在当前事务启动之后做的。
2) 创建版本号小于或者等于当前事务版本号，就是说记录创建是在事务中（等于的情况）或者事务启动之前。
保证了各个事务互不影响。从这里也可以体会到一种提高系统性能的思路就是： 通过版本号来减少锁的争用。
另外，只有read-committed和 repeatable-read 两种事务隔离级别才能使用MVCC
read-uncommited由于是读到未提交的，所以不存在版本的问题
而serializable 则会对所有读取的行加锁。
存储引擎
此处只列举两种，MyISAM 与 InnoDb
InnoDb
- 支持ACID的事务，支持事务的四种隔离级别；
- 支持行级锁及外键约束：因此可以支持写并发；
- 不存储总行数；
- 一个InnoDb引擎存储在一个文件空间（共享表空间，表大小不受操作系统控制，一个表可能分布在多个文件里），也有可能为多个（设置为独立表空，表大小受操作系统文件大小限制，一般为2G），受操作系统文件大小的限制；
- 主键索引采用聚集索引（索引的数据域存储数据文件本身），辅索引的数据域存储主键的值；因此从辅索引查找数据，需要先通过辅索引找到主键值，再访问辅索引；最好使用自增主键，防止插入数据时，为维持B+树结构，文件的大调整。
MyISAM
- 不支持事务，但是每次查询都是原子的；
- 支持表级锁，即每次操作是对整个表加锁；
- 存储表的总行数；
- 一个MYISAM表有三个文件：索引文件、表结构文件、数据文件；
- 采用菲聚集索引，索引文件的数据域存储指向数据文件的指针。辅索引与主索引基本一致，但是辅索引不用保证唯一性。
InnoDb与MyISAM索引的区别
两种存储引擎都是采用B+Tree的结构
MYISAM的主索引结构如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-zFDnyqwB-1578388117322)(http://blog.guowenbo.top/images/2018-12-03/mysql_1.png)]
辅索引如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MPdq5MAl-1578388117323)(http://blog.guowenbo.top/images/2018-12-03/mysql_2.png)]
InnoDb的主索引如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LuGOaMsI-1578388117323)(http://blog.guowenbo.top/images/2018-12-03/mysql_3.png)]
辅索引如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bRJUnDE2-1578388117324)(http://blog.guowenbo.top/images/2018-12-03/mysql_4.png)]
两种索引数据查找过程如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-74lvtNHC-1578388117324)(http://blog.guowenbo.top/images/2018-12-03/mysql_5.png)]