一文详解MySQL事务和锁

　　事务概述
　　当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性：原子性（Atomicity）：事务中所有操作视为一个原子单位，即对事务所进行的数据修改等操作只能是完全回滚或完全提交一致性（Consistency）：事务在完成时，必须使用所有的数据从一种一致性变更为另一种一致性状态，所有的变更都必须应用于事务的修改，以确保数据的完整性。事务的一致性由原子性、持久性和隔离性一起实现隔离性（Isolation）：一个事务中的操作语句所做的修改必须与其他事务所做的修改相隔离。在进行事务查看数据时，数据所处的状态，要么是被另一个并发事务修改之前的状态，要么是被另一并发事务修改之后的状态，即当前事务不会查询由另一个并发事务正在修改的数据。隔离性由MySQL锁机制实现持久性（Durability）：事务完成之后，所做的修改对数据的影响是永久的，即使系统重启或者出现系统故障，数据仍可恢复
　　MySQL提供了多种事务型存储引擎，如InnoDB和BDB等，而MyISAM不支持事务。为了支持事务，InnoDB存储引擎引入了与事务处理相关的REDO日志和UNDO日志，同时事务依赖于MySQL提供的锁机制1。REDO日志
　　事务执行时需要将执行的事务日志写入日志文件，对应的文件为REDO日志。当每条SQL进行数据更新操作时，首先将REDO日志写进日志缓冲区。当客户端执行COMMIT命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数innodbflushlogattrxcommit控制
　　REDO日志对应磁盘上的iblogifleN文件，该文件默认为5MB，建议设置为512MB，以便容纳较大的事务。MySQL崩溃恢复时会重新执行REDO日志的记录，恢复最新数据，保证已提交事务的持久性2。UNDO日志
　　与REDO日志相反，UNDO日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到UNDO缓冲区，然后在合适的时间将内容刷新到磁盘
　　假如由于系统错误或者rollback操作而导致事务回滚，可以根据undo日志回滚到没修改前的状态，保证未提交事务的原子性
　　与REDO日志不同的是，磁盘上不存在单独的UNDO日志文件，所有的UNDO日志均存在表空间对应的。ibd数据文件中，即使MySQL服务启动了独立表空间事务控制语句
　　在MySQL中，可以使用BEGIN开始事务，使用COMMIT结束事务，中间可以使用ROLLBACK回滚事务。MySQL通过SETAUTOCOMMIT、STARTTRANSACTION、COMMIT和ROLLBACK等语句支持本地事务STARTTRANSACTIONBEGIN〔WORK〕COMMIT〔WORK〕ROLLBACK〔WORK〕SETAUTOCOMMIT｛01｝BEGINSTARTTRANSACTION：开始事务COMMIT：结束事务ROLLBACK：回滚事务WORK：SQL语句SETAUTOCOMMIT：是否自动提交，0禁止，1开启，默认为1事务隔离级别
　　MySQL定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少
　　InnoDB系统级事务隔离级别可以使用以下语句设置：SETGLOBALTRANSACTIONISOLATIONLEVELREADUNCOMMITTED；SETGLOBALTRANSACTIONISOLATIONLEVELREADCOMMITTED；SETGLOBALTRANSACTIONISOLATIONLEVELREPEATABLEREAD；SETGLOBALTRANSACTIONISOLATIONLEVELSERIALIZABLE；
　　查看系统级事务隔离级别：SELECTglobal。
　　InnoDB会话级事务隔离级别可以使用以下语句设置：SETSESSIONTRANSACTIONISOLATIONLEVELREADUNCOMMITTED；SETSESSIONTRANSACTIONISOLATIONLEVELREADCOMMITTED；SETSESSIONTRANSACTIONISOLATIONLEVELREPEATABLEREAD；SETSESSIONTRANSACTIONISOLATIONLEVELSERIALIZABLE；
　　查看会话级事务隔离级别：SELECT1。读未提交
　　在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据称为脏读（DirtyRead），即是：首先开启A和B两个事务，在B事务更新但未提交之前，A事务读取到了更新后的数据，但由于B事务回滚，导致A事务出现了脏读现象2。读已提交
　　所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（NonrepeatableRead）：首先开启A和B两个事务，A事务读取了B事务的数据，在B事务更新并提交后，A事务又读取到了更新后的数据，此时就出现了同一A事务中的查询出现了不同的查询结果3。可重复读
　　MySQL默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（PhontomRead）。例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行
　　InnoDB通过多版本并发控制机制（MVCC）解决了该问题：InnoDB通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果4。串行化
　　通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用InnoDB锁机制
　　为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询操作，需要对并发操作进行控制，因此产生了锁1。锁的类型1。1共享锁
　　共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读操作1。2排他锁
　　排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写操作
　　有两个事务A和B，如果事务A获取了一个元组的共享锁，事务B还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务A释放共享锁之后。如果事务A获取了一个元组的排他锁，事务B不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到A释放排他锁之后1。3意向锁
　　意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。意向共享锁表示一个事务有意对数据上共享锁或者排他锁。有意表示事务想执行操作但还没真正执行2。锁的粒度
　　锁的粒度主要分为表锁和行锁
　　表锁的开销最小，同时允许的并发量也是最小。MyISAM存储引擎使用该锁机制。当要写入数据时，整个表记录被锁，此时其他读写动作一律等待。一些特定的动作，如ALTERTABLE执行时使用的也是表锁
　　行锁可以支持最大的并发，InnoDB存储引擎使用该锁机制。如果要支持并发读写，建议采用InnoDB存储引擎
　　原文链接：https：www。cnblogs。comYeeQp16209147。html？utmsourcetuicoolutmmediumreferral