在面试中，基本上都会问到关于数据库的事务问题，如果啥都不会或者只回答到表面的上知识点的话，那面试基本上是没戏了，为了能顺利通过面试，那MySql的事务问题就需要了解，所以就根据网上的资料总结一版Mysql事务的知识点，巩固一下事务的知识。
事务
事务是指逻辑上的一组操作，要么都执行，要么都不执行,
事务的特性(ACID)
原子性(Atomicity)：事务是不可分割的工作单元，要么都成功，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。
一致性(Consistency)：事务不能破坏数据的完整性和业务的一致性 。例如在银行转账时，不管事务成功还是失败，双方钱的总额不变
隔离性(Isolation)：一个事务所操作的数据在提交之前，对其他事务的可见性设定(一般是不可见)
持久性(Durability)：事务提交之后，所做的修改就会永久保存，不会因为系统故障导致数据丢失
严格来说，只有同时满足站长博客数据库的事务ACID特性才能算一个完整的事务，但现实中实现能够真正满足的完整的事务特性少之又少，但是在实现中也必须尽量达到事务要求的特性。
那么事务ACID特性具体怎么实现的呢？我们来分析看看，首先先看看事务的特性。
原子性(Atomicity)
首先我们来看看事务的原子性特性，看看其如何实现的？
原子性(Atomicity)：事务是不可分割的工作单元，要么都成功，要么都失败， 如果事务中一个sql语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态
原子性(Atomicity)的实现离不开 MySQL的事务日志 undo log日志类型，当事务需要回滚的时候需要将数据库状态回滚到事务开始前，即需要撤销所有已经成功执行的sql语句。那么undo log起了关键性作用：
当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。
那么undo log是什么呢？每个数据变更操作是怎么被记录下来的呢？
undo log( 回滚日志 )
undo log (回滚日志)：是采用段(segment)的方式来记录的，每个undo操作在记录的时候占用一个undo log segment。为什么会在数据更改操作的时候，记录了相对应的undo log呢？其目的在于：
为了保证数据的原子性，记录事务发生之前的一个版本，用于回滚，
通过mvcc+undo log实现innodb事务可重复读和读取已提交隔离级别。
其中，undo log分为：
insert undo log ： insert操作中产生的undo log，
update undo log： 对delete 和update操作产生的undo log
数据更改的undo log怎么记录的呢？
因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作，
而Delete操作在事务中实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作需要后台purge线程去完成。
update分为两种情况：update的列是否是主键列。
如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。
如果是主键列，update分两部执行：先删除该行，再插入一行目标行。
与insert undo log 不同的，update undo log日志，当事务提交的时候，innodb不会立即删除undo log， 会将该事务对应的undo log放入到删除列表中，未来通过purge线程来删除。
因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除(即undo log不能删除),且undo log分配的页可重用减少存储空间和提升性能。
Note： purge线程两个主要作用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。
接着我们来看看事务的隔离性，看看事务有哪些隔离级别，而且事务并发中会产生什么问题。
隔离性(Isolation)
隔离性(Isolation)，是指事务内部的操作与其他事务是隔离的，并发执行的各个事务之间不能互相干扰 ，一个事务所操作的数据在提交之前，对其他事务的可见性设定(一般是不可见)。
事务隔离级别
而且数据库为了在并发下有效保证读取数据正确性，数据库提供了四种事务隔离级别，分别为：
读未提交(脏读)：允许读取尚未提交的数据，允许脏读
读已提交( 不可重复读 )：允许读取事务已经提交的数据
可重复读( 幻读 )：在同一个事务内的查询结果都是和事务开始时刻查询一致的( InnoDB默认级别 )
串行化：所有事务逐个依次执行， 每次读都需要获得表级共享锁，读写相互都会阻塞
其中，不同的隔离级别可能会存在在不同并发问题，主要并发问题包括：
数据丢失： 两个或多个事务操作相同数据，基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新
脏读：读到了其他事务还未提交的数据，事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据
不可重复读(重点是修改)：在一个事务中，先后进行两次相同的读取，由于另一个事务修改了数据，导致前后两次结果的不一致，事务A多次读取同一数据，事务B在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。幻读(重点是新增、删除)： 在一个事务中，先后进行两次相同的读取(一般是范围查询)，由于另一个事务新增或删除了数据，导致前后两次结果不一致
不可重复读和幻读的区别？
不可重复读和幻读最大的区别，就在于如何通过锁机制来解决他们产生的问题，
使用锁机制来实现这两种隔离级别，在可重复读中，相同sql第一次读取到数据后就将这些数据加锁，其它事务无法更新操作这些数据来实现可重复读了隔离。
但这种处理方式却无法锁住insert的数据，因此会出现当事务A先前读取了数据，事务B再insert数据提交，结果发现事务A就会发现莫名其妙多了些数据，这就是幻读，不能通过行锁来避免 。
了解了并发问题后，来看看不同的隔离级别可能会存在在不同并发问题：
为了实现事务隔离，延伸出了数据库锁。其中，innodb事务的隔离级别是由锁机制和MVCC(多版本并发控制)来实现的
那我们来先看看锁的原理，怎么使用锁来实现事务隔离的呢？
锁机制
锁机制的基本工作原理，事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁，
MySQL主要分成三种类型(级别)的锁机制：
表级锁：最大颗粒度的锁机制，锁定资源争用的概率也会最高 ，并发度最低 ，但开销小，加锁快，不会出现死锁，
行级锁：最大颗粒度的锁机制很小， 发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能 ，但 开销大，加锁慢；会出现死锁 ，
页级锁： 开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般
而且不同的存储引擎支持不同的的锁机制，主要分析一下InnoDB锁。
InnoDB锁
InnoDB实现了以下两种类型的行锁
共享锁(S锁、行锁)：多个事务对同一数据行可以共享一把锁，只能读不能修改
排它锁(X锁、行锁)：一个事务获取一个数据行的排它锁，那么其他事务将不能再获取该行的锁(共享锁、排它锁)， 允许获取排他锁的事务更新数据
对于UPDATE,DELETE,INSERT操作， InnoDB会自动给涉及及数据集加排他锁(Ｘ)；对于普通SELECT语句，InnoDB不会加任何锁,
而且因为InnoDB引擎允许行锁和表锁共存，实现多粒度锁机制，使用意向锁实现表锁机制，
意向共享锁(IS锁、表锁)：当事务准备给数据行加共享锁时，会先给表加上一个意向共享锁。意向共享锁之间是兼容的
意向排它锁(IX锁、表锁)：当事务准备给数据行加排它锁时，会先给表加上一个意向排它锁。意向排它锁之间是兼容的
意向锁(IS、IX)是InnoDB数据操作之前自动加的，不需要用户干预。它的意义在于：当事务想去进行锁表时，可以先判断意向锁是否存在，存在时则可快速返回该表不能启用表锁，否则就需要等待，
其中，四种锁的兼容性如下
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就请求的锁授予该事务；反之，如果两者两者不兼容，该事务就要等待锁释放。
InnoDB行锁
InnoDB的行锁是通过给索引上的索引项加锁来实现的。只有通过索引检索数据，才能使用行锁，否则将使用表锁(锁住索引的所有记录)
临键锁(next-key)，可以防止幻读。根据索引，划分为一个个左开右闭的区间。当进行范围查询的时候，若命中索引且能够检索到数据，则锁住记录所在的区间和它的下一个区间,
其实，临键锁(Next-Key)=记录锁(Record Locks)+间隙锁(Gap Locks)，
当我们用范围条件检索数据而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合范围条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做间隙(GAP)。
当使用唯一索引，且记录存在的精准查询时，使用Record Locks记录锁
