MySQL事务的四大特性

一、事务的四个特性

• 原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。
• 一致性（Consistency）：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成的事务对数据库所作的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。比如A向B转账，不可能A扣了钱，B却没收到。
• 隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。
• 持久性（Durability）：指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

二、实现方式

2.1 原子性

InnoDB引擎通过使用undo log来实现事务的原子性。当需要对事务进行回滚时，InnoDB引擎会利用undo log撤销SQL语句，从而达到数据回滚的目的。

undo log在事务对数据库进行修改时创建。若事务执行失败或者调用了rollback导致事务必须回滚，便可通过undo log中的信息将数据回滚到修改前的状态。

当发生回滚时，InnoDB引擎会根据undo log日志中的记录做与之前相反的工作。比如对于每个数据的插入操作，回滚时会执行数据删除操作；对于每个数据删除操作，回滚时会执行数据插入操作；对于每个数据更新操作，回滚时会执行一个相反的数据更新操作，把数据改回去。undo log不仅提供了回滚功能，还可以实现MVCC。

2.2 持久性

事务的持久性通过InnoDB存储引擎中的redo log实现。

redo log是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。InnoDB引擎对数据的更新，是先将更新记录写入redo log日志，然后会在系统空闲的时候或者是按照设定的更新策略再将日志中的内容更新到磁盘之中。这就是所谓的预写式技术（Write Ahead logging）。这种技术可以大大减少IO操作的频率，提升数据刷新的效率。

redo log有一些细节需要我们注意：它的大小是固定的，为了能够持续不断的对更新记录进行写入，在redo log日志中设置了两个标志位置，checkpoint和write_pos，分别表示记录擦除的位置和记录写入的位置。这种结构很像一个循环队列：

2.3 隔离性

事务之间的隔离，是通过锁机制或者MVCC（多版本并发控制）实现的。当一个事务需要对数据库中的某行数据进行修改时，需要先给数据加锁。加了锁的数据，其它事务是不运行操作的，只能等待当前事务提交或回滚将锁释放。锁机制并不是一个陌生的概念，在许多场景中都会利用到不同实现的锁对数据进行保护和同步。而在MySQL中，根据不同的划分标准，还可将锁分为不同的种类。

• 按照粒度划分：行锁、表锁、页锁
• 按照使用方式划分：共享锁、排他锁
• 按照思想划分：悲观锁、乐观锁

接下来按上面的顺序介绍下这些锁的类别和特点：

2.3.1 粒度（行锁、表锁、页锁）

从锁的粒度这个方面来看，表锁在操作数据时会锁定整张表，因而并发性能较差。行锁则只锁定需要操作的数据，并发性能好，但是由于加锁本身需要消耗资源(获得锁、检查锁、释放锁等都需要消耗资源)，因此在锁定数据较多情况下使用表锁可以节省大量资源。页锁是粒度介于行级锁和表级锁中间的一种锁，表示对页进行加锁。

MySQL中不同的存储引擎能够支持的锁也是不一样的。MyISAM只支持表锁，而InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB会通过隐藏的聚簇索引来对记录加锁。也就是说，如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。因为没有了索引，找到某一条记录就得扫描全表，要扫描全表，就得锁定表。

2.3.2 使用方式（共享锁、排他锁）

共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。

排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁。获取排他锁的事务是可以对数据就行读取和修改。

注意：对于select语句，InnoDB不会加任何锁，也就是可以多个并发去进行select的操作，不会有任何的锁冲突，因为根本没有锁。对于insert，update，delete操作，InnoDB会自动给涉及到的数据加排他锁，只有查询select需要我们手动设置排他锁。

2.3.3 思想（悲观锁、乐观锁）

悲观锁（Pessimistic Concurrency Control），正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制 （也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。悲观锁通过常用的select … for update操作来实现悲观锁，悲观锁的流程也被称为：一锁二查三更新。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。另外，在只读型事务处理中由于不会产生冲突，也没必要使用锁，这样做只能增加系统负载。还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。乐观锁通常使用版本标识方法来实现，比如MVCC。

乐观并发控制相信事务之间的数据竞争（data race）的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。

2.4 一致性

一致性是通过持久性+原子性+隔离性来保证的。

一致性是指事务执行结束后，数据库的完整性约束没有被破坏，事务执行的前后都是合法的数据状态。一致性是事务追求的最终目标，原子性、持久性和隔离性，实际上都是为了保证数据库状态的一致性而存在的。

换句话说，ACID里的AID都是数据库的特征，也就是依赖数据库的具体实现。而唯独这个C，实际上它依赖于应用层，也就是依赖于开发者。这里的一致性是指系统从一个正确的状态，迁移到另一个正确的状态。什么叫正确的状态呢？就是当前的状态满足预定的约束就叫做正确的状态。而事务具备ACID里C的特性是说通过事务的AID来保证我们的一致性。