MySQL事务基础知识
Posted 蚂蚁小哥
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MySQL事务基础知识相关的知识，希望对你有一定的参考价值。
一：数据库事务概述
事务是数据库的重要特性之一，当我们有了事务就会让数据库始终保持一致性，同时我们还能通过事务的机制恢复到某个时间点，这样可以保证已提交到数据库的修改不会因为系统崩溃而丢失。因为事务保证这些操作要么完全地执行，要么完全地都不执行，它是一个不可分割的工作执行单元。我们可以通过执行 SHOW ENGINES 命令来查看当前MySQL支持的存储引擎都有哪些，以及这些存储引擎是否支持事务。
1：基本概念
事务：
一组逻辑操作单元，使数据从一种状态变换到另一种状态。
事务处理的原则：
保证所有事务都作为一个工作单元来执行，即使出现了故障，都不能改变这种执行方式。当在一个事务中执行多个操作时，要么所有的事务
都被提交(COMMIT),那么这些修改就永久地保存下来;要么数据库管理系统将放弃所作的所有修改,整个事务回滚(ROLLBACK)到最初状态。
示例：现在小明小红发生了转账操作（假设都有100元，小明给小红转账100元）
UPDATE account SET money = money - 100 WHERE name = "小明";
UPDATE account SET money = money + 100 WHERE name = "小红";
上面的2条SQL可以被认为是一个事务，其中有任何一条SQL语句执行错误或系统宕机都会导致数据恢复到最初执行这两条语句前(ROLLBACK)
但是这两条SQL都执行成功的话则会提交事务(COMMIT)
2：事务的ACID特性
Ⅰ：原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，要么全部提交，要么全部失败回滚。即要么转账成功，要么转账失败，是不存在中间的状态。
如果无法保证原子性会就会出现数据不一致的情形，如A账户减去100元执行成功，而B账户增加100元执行失败，系统将无故丢失100元。
Ⅱ：隔离性（Isolation）
事务的隔离性是指一个事务的执行不能被其它事务干扰，即一个事务内部的操作及使用的数据对并发的其它事务是隔离的，并发执行的各个
事务之间不能互相干扰。如果无法保证隔离性则会出现问题，假设A账户有200元，B账户0元。A账户往B账户转账两次，每次金额为50元，
分别在两个事务中执行。如果无法保证隔离性,会出现下面的情形（T1代表事务1，T2代表事务2）:
UPDATE accounts SET money = money - 50 WHERE `name` = \'A\';
UPDATE accounts SET money = money + 50 WHERE `name` = \'B\';
+--------+-----------------------------------------+----------------------------------------+
|时间线 | T1（事务1） | T2（事务2） |
+--------+-----------------------------------------+----------------------------------------+
| 1 | 从磁盘上将A账户余额读到变量A中【内存A为200】 | |
| 2 | 执行操作A=A-50 | |
| 3 | 将A的值回写到磁盘【磁盘A为150】 | |
| 4 | 从磁盘上将B账户余额读到变量B中【内存B为0】 | |
| 5 | 执行操作B=B+50 | |
| 6 | | 从磁盘上将A账户余额读到变量A中【内存A为150】 |
| 7 | | 执行操作A=A-50 |
| 8 | | 将A的值回写到磁盘【磁盘A为100】 |
| 9 | | 从磁盘上将B账户余额读到变量B中【内存B为0】 |
| 10 | | 执行操作B=B+50 |
| 11 | | 将B值回写到磁盘【回写B的值为50到磁盘】 |
| 12 | 将B值回写到磁盘【回写B的值为50到磁盘】 | |
+--------+-----------------------------------------+----------------------------------------+
可以发现，若两个事务之间不进行隔离，那就会读取到其它事务的数据，就会导致不正常，最终发现转账金额对不上
Ⅲ：一致性（Consistency）
根据定义，一致性是指事务执行前后，数据从一个合法性状态变换到另外一个合法性状态。这种状态是语义上的而不是语法上的，跟具体的业
务有关。满足预定约束的状态就叫做合法的状态。简单说就是这状态是由你自己来定义的(比如满足现实世界中的约束)。满足这个状态，数
据就是一致的，不满足这个状态数据就是不一致的，如果事务中的某个操作失败了，系统就会自动撤销当前正在执行的事务，返回到事务操
作之前的状态。
合法性状态指的是现实世界的约束和数据库的约束是OK的，不存在任何问题的，则就是合法性状态。
举例1：A账户有200元，转账300元出去，此时A账户余额为-100元。你会发现了此时数据是不一致的, 因为你定义了一个状态，
余额这列必须>=0。
举例2：A账户有200元，转账50元给B账户，A账户的钱扣了，但是B账户因为各种意外，余额并没有增加。你也知道此时数据是不一致
的，因为你定义了一个状态，要求A+B的总余额必须不变。
举例3：在数据表中我们将姓名字段设置为唯一性约束，这时当事务进行提交或者事务发生回滚的时候，如果数据表中的姓名不唯一，
就破坏了事务的一致性要求。
总结：一般在定义一致性需求时，只要某些数据库操作满足原子性和隔离性规则，那么结果就会满足一致性要求。
Ⅳ：持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来的其它操作和数据库故障不应该对其有任何影响。
持久性是通过事务日志来保证的。日志包括了重做日志和回滚日志。当我们通过事务对数据进行修改的时候，首先会将数据库的变化信息
记录到重做日志中，然后再对数据库中对应的行进行修改。这样做的好处是，即使数据库系统崩溃，数据库重启后也能找到没有更新到
数据库系统中的重做日志，重新执行，从而使事务具有持久性。
总结：
ACID是事务的四大特性，在这四个特性中，原子性是基础，隔离性是手段，一致性是约束条件，而持久性是我们的目的。
数据库事务，其实就是数据库设计者为了方便起见，把需要保证原子性、隔离性、一致性和持久性的一个或多个数据库操作称为一个事务。
3：事务的状态
我们现在知道事务是一个抽象的概念，它其实对应着一个或多个数据库操作，MySQL根据这些操作所执行的不同阶段把事务大致划分成几个状态:
Ⅰ：活动的(active) 事务对应的数据库操作正在执行过程中时，我们就说该事务处在活动的状态。 Ⅱ：部分提交的(partially committed) 当事务中的最后一个操作执行完成，但由于操作都在内存中执行，所造成的影响并没有刷新到磁盘时，我们就说该事务处在部分提交的状态。 Ⅲ：失败的(failed) 当事务处在活动的或者部分提交的状态时，可能遇到了某些错误（数据库自身的错误、操作系统错误或者直接断电等）而无法继续执行，或 者人为的停止当前事务的执行，我们就说该事务处在失败的状态。 Ⅳ：中止的(aborted) 如果事务执行了一部分而变为失败的状态，那么就需要把已经修改的事务中的操作还原到事务执行前的状态。换句话说，就是要撤销失败事 务对当前数据库造成的影响。我们把这个撤销的过程称之为回滚。当回滚操作执行完毕时，也就是数据库恢复到了执行事务之前的状态，我 们就说该事务处在了中止的状态。 举例: UPDATE accounts SET money = money - 50 WHERE `name` = \'AA\' ; UPDATE accounts SET money = money + 50 WHERE `name` = \'BB\' ; Ⅴ：提交的(committed) 当一个处在部分提交的状态的事务将修改过的数据都同步到磁盘上之后，我们就可以说该事务处在了提交的状态。 一个基本的状态转换图如下所示:
上图可见，只有当事务处于提交的或者中止的状态时，一个事务的生命周期才算是结束了。对于已经提交的事务来说，该事务对数据库所做的修改
将永久生效，对于处于中止状态的事务，该事务对数据库所做的所有修改都会被回滚到没执行该事务之前的状态。
二：如何使用事务
前面只是介绍了事务的ACID特性，其实MySQL是如何将一系列的操作放到一个事务中执行的呢？这就需要我们了解事务创建的两种方式，分别是显示事务和隐式事务。
事务创建过程：(步骤1：开启事务) --> (步骤2：执行一系列DML操作) --> (步骤3：事务结束状态（提交事务COMMIT，中止事务ROLLBACK）)
1：显示创建事务
步骤一：开启事务 开始事务第一种方式：BEGIN [WORK] 执行BEGIN就代表开启了一个事务，后面的WORK单词可有可无，意思是一样的，开启后就可以在事务内执DML等其它操作 开启事务第二种方式：START TRANSACTION START TRANSACTION语句相较于BEGIN特别之处在于，后边能跟随几个修饰符: ①READ ONLY：标识当前事务是一个只读事务，也就是属于该事务的数据库操作只能读取数据，而不能修改数据。 ②READ WRITE：标识当前事务是一个读写事务，也就是属于该事务的数据库操作既可以读取数据，也可以修改数据。 ③WITH CONSISTENT SNAPSHOT: 启动一致性读。 补充：只读事务中只是不允许修改那些其它事务也能访问到的表中的数据，对于临时表来说(我们使用CREATE TMEPORARY TABLE创建表), 由于它们只能在当前会话中可见，所以只读事务其实也是可以对临时表进行增、删、改操作的。 START TRANSACTION READ ONLY; START TRANSACTION READ ONLY,WITH CONSISTENT SNAPSHOT; START TRANSACTION READ WRITE,WITH CONSISTENT SNAPSHOT; 注意： ①：READ ONLY和READ WRITE是用来设置所谓的事务访问模式的，就是以只读还是读写的方式来访问数据库中的数据，一个事务的访 问模式不能同时设置为只读的也设置为读写的，所以不能同时把READ ONLY和READ WRITE放到START TRANSACTION语句后边。 ②：如果我们不显式指定事务的访问模式，那么该事务的访问模式就是读写模式（READ WRITE）。 步骤二：一系列事务中的操作(主要是DML，不含DDL) 步骤三：提交事务或中止事务(即回滚事务) mysql> COMMIT; mysql> ROLLBACK; mysql> ROLLBACK TO [SAVEPOINT] 其中关于SAVEPOINT(保存点)相关操作有: SAVEPOINT 保存点名称; RELEASE SAVEPOINT 保存点名称: 保存点其实就是在事务内的某个阶段创建一个保存点，若后面执行出现问题则可以回滚到指定保存点，而不用整个回滚。 开启事务->SQLA->SQLB->保存点1->SQLC->回滚保存点1；回滚后就代表当前事务内只执行了SQLA和SQLB语句，而SQLC被回滚；
2：隐式创建事务
其实MySQL中有一个系统变量：autocommit
查询：SHOW VARIABLES LIKE \'autocommit\'; --默认NO开启状态，代表自动提交事务
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
默认情况下，如果我们不显式的使用START TRANSACTION或者BEGIN语句开启一个事务，那么每一条语句都算是一个独立的事务，这种特性称
之为事务的自动提交。也就是说，不以START TRANSACTION或者BEGIN语句显式的开启一个事务，那么下边这两条语句就相当于放到两个独立
的事务中去执行:
UPDATE accounts SET balance = balance - 10 WHERE id = 1; --这条DML操作是独立的事务和下面没有关系
UPDATE accounts SET balance = balance + 10 WHERE id = 2; --这条DML操作是独立的事务和上面没有关系
当然，如果我们想关闭这种自动提交的功能，可以使用下边两种方法之一:
①：显式的的使用START TRANSACTION或者BEGIN语句开启一个事务。这样在本次事务提交或者回滚前会暂时关闭掉自动提交的功能。
②：把系统变量autocommit的值设置为OFF（关闭），就像这样：SET autocommit = 0FF; 或 SET autocommit = 0;
这样的话，我们写入的多条语句就算是属于同一个事务了，直到我们显式的写出COMMIT语句来把这个事务提交掉，或者显式的写出ROLLBACK
语句来把这个事务回滚掉。
补充: Oracle 默认不自动提交，需要手写COMMIT命令，而MySQL默认自动提交。
3：事务隐式提交
其实在某些时候，我执行了一些其它SQL语句，如DDL则也会触发自动提交事务，而无需我们手动执行COMMIT了。
Ⅰ：数据定义语言(Data Definition Language，缩写为: DDL) 数据库对象，指的就是数据库、表、视图、存储过程等结构。当我们使用CREATE、ALTER、DROP等语句去修改数据库对象时，就会隐式的 提交前边语句所属于的事务。即: BEGIN; SELECT ... UPDATE ... ... CREATE TABLE ... Ⅱ：隐式使用或修改MySQL数据库中的表 当我们使用ALTER USER(修改用户)、CREATE USER(创建用户)、 DROP USER(删除用户)、GRANT(用户授权)、REVOKE(收回权限)、 RENAME USER(修改用户)、SET PASSWORD(密码修改)等语句时也会隐式的提交前边语句所属于的事务。 Ⅲ：事务控制或关于锁定的语句 ①：在一个事务还没提交或者回滚时就又使用START TRANSACTION或者BEGIN语句开启了另一个务时，会隐式的提交上一个事务。即: BEGIN; SELECT ... UPDATE ... ... BEGIN; ②：当前的autocommit系统变量的值为0FF，我们手动把它调为ON时，也会隐式的提交前边语句所属的事务。 ③：使用LOCK TABLES、UNLOCK TABLES等关于锁定的语句也会隐式的提交前边语句所属的事务。 Ⅳ：加载数据的语句 使用LOAD DATA语句来批量往数据库中导入数据时，也会隐式的提交前边语句所属的事务。 Ⅴ：关于MySQL复制的一些语句 使用START SLAVE、STOP SLAVE、RESET SLAVE、CHANGE MASTER TO等语句时会隐式的提交前边语句所属的事务。 Ⅵ：其它的一些语句 使用ANALYZE TABLE、CACHE INDEX、CHECK TABLE、FLUSH、LOAD INDEX INTO CACHE、OPTIMIZE TABLE、REPAIR TABLE、 RESET等语句也会隐式的提交前边语句所属的事务。
4：事务常见分类
从事务理论的角度来看，可以把事务分为以下几种类型:
①：扁平事务(Flat Transactions)
②：带有保存点的扁平事务(Flat Transactions with Savepoints)
③：链事务(Chained Transactions)
④：嵌套事务(Nested Transactions)
⑤：分布式事务(Distributed Transactions)
下面分别介绍这几种类型:
Ⅰ：扁平事务（重点，就是我们常用的）
这个是事务类型中最简单的一种，但是在实际生产环境中，这可能是使用最频繁的事务，在扁平事务中，所有操作都处于同一层次，
其由BEGIN [WORK]开始，由COMMIT [WORK]或ROLLBACK [WORK]结束，其间的操作是原子的，要么都执行，要么都回滚，因此，
扁平事务是应用程序成为原子操作的基本组成模块。扁平事务虽然简单，但是在实际环境中使用最为频繁，也正因为其简单，使用频繁，
故每个数据库系统都实现了对扁平事务的支持。扁平事务的主要限制是不能提交或者回滚事务的某一部分，或分几个步骤提交。
扁平事务一般有三种不同的结果:
①：事务成功完成。在平常应用中约占所有事务的96%。
②：应用程序要求停止事务。比如应用程序在捕获到异常时会回滚事务，约占事务的3%。
③：外界因素强制终止事务。如连接超时或连接断开，约占所有事务的19%。
Ⅱ：带有保存点的届平事务
这个事务除了支持扁平事务的操作外，还允许在事务执行过程中回滚到当前事务中较早的一个状态。这是因为某些事务可能在执行过程中出
现的错误并不会导致所有的操作都无效，放弃整个事务不合乎要求，开销太大。
保存点(Savepoint)用来通知事务系统应该记住事务当前的状态，以便当之后发生错误时，事务能回到保存点当时的状态。对于扁平
的事务来说，隐式的设置了一个保存点，然而在整个事务中，只有这一个保存点，因此，回滚只能会滚到事务开始时的状态。
Ⅲ：链事务
这个事务由多个子事务链式组成，它可以被视为保存点模式的一个变种。带有保存点的扁平事务，当发生系统崩溃时,所有的保存点都将消失，
这意味着当进行恢复时，事务需要从开始处重新执行，而不能从最近的一个保存点继续执行。
链事务的思想是：在提交一个事务时，释放不需要的数据对象，将必要的处理上下文隐式地传给下一个要开始的事务，前一个子事务的提交操
作和下一个子事务的开始操作合并成一个原子操作，这意味着下一个事务将看到上一个事务的结果，就好像在一个事务中进行一样。这样，在
提交子事务时就可以释放不需要的数据对象，而不必等到整个事务完成后才释放。其工作方式如下:
链事务与带有保存点的扁平事务的不同之处体现在:
①带有保存点的扁平事务能回滚到任意正确的保存点，而链事务中的回滚仅限于当前事务，即只能恢复到最近的一个保存点。
②对于锁的处理，两者也不相同，链事务在执行COMMIT后即释放了当前所持有的锁，而带有保存点的扁平事务不影响迄今为止所持有的锁。
Ⅳ：嵌套事务
是一个层次结构框架，由一个顶层事务(Top-Level Transaction)控制着各个层次的事务，顶层事务之下嵌套的事务被称为子事务
(Subtransaction)，其控制着每一个局部的变换，子事务本身也可以是嵌套事务。因此，嵌套事务的层次结构可以看成是一棵树。
Ⅴ：分布式事务
通常是在一个分布式环境下运行的扁平事务，因此，需要根据数据所在位置访问网络中不同节点的数据库资源。例如，一个银行用户从招商银
行的账户向工商银行的账户转账1000元，这里需要用到分布式事务，因为不能仅调用某一家银行的数据库就完成任务。
5：事务的常见操作
数据准备： CREATE TABLE IF NOT EXISTS transaction_demo( tid INT PRIMARY KEY AUTO_INCREMENT COMMENT \'主键ID\', tname VARCHAR(5) NOT NULL UNIQUE KEY COMMENT \'姓名\') ENGINE=INNODB; 案例1（正常事务，遵循了事务的ACID）： BEGIN; INSERT INTO transaction_demo (tname) VALUES (\'张小一\'); INSERT INTO transaction_demo (tname) VALUES (\'张小二\'); COMMIT; 案例2（异常事务，未保证事务的一致性）： BEGIN; INSERT INTO transaction_demo (tname) VALUES (\'张小三\'); INSERT INTO transaction_demo (tname) VALUES (\'张小三\'); ROLLBACK; 案例3（DDL语句一旦在事务内执行，则本次事务被强制提交）： TRUNCATE TABLE transaction_demo; BEGIN; INSERT INTO transaction_demo (tname) VALUES (\'张小一\'); CREATE TABLE demo1(`tname` VARCHAR(5)); 案例4（带有保存点的事务）： TRUNCATE TABLE transaction_demo; BEGIN; INSERT INTO transaction_demo (tname) VALUES (\'张小一\'); INSERT INTO transaction_demo (tname) VALUES (\'张小二\'); SAVEPOINT tran1; INSERT INTO transaction_demo (tname) VALUES (\'张小三\'); INSERT INTO transaction_demo (tname) VALUES (\'张小四\'); ROLLBACK TO tran1; COMMIT;
三：事务的隔离级别
MySQL是一个客户端/服务器架构的软件，对于同一个服务器来说，可以有若干个客户端与之连接，每个客户端与服务器连接上之后，就可以称为一个会话(Session)。每个客户端都可以在自己的会话中向服务器发出请求语句，一个请求语句可能是某个事务的一部分，也就是对于服务器来说可能同时处理多个事务。事务有隔离性的特性，理论上在某个事务对某个数据进行访问时，其它事务应该进行排队（这种方式为串行化），当该事务提交之后，其它事务才可以继续访问这个数据。但是这样对性能影响太大，我们既想保持事务的隔离性，又想让服务器在处理访问同一数据的多个事务时性能尽量高些，那就看二者如何权衡取舍了。
CREATE TABLE IF NOT EXISTS student_demo( sid INT PRIMARY KEY AUTO_INCREMENT COMMENT \'主键ID\', sname VARCHAR(5) NOT NULL UNIQUE KEY COMMENT \'姓名\') ENGINE=INNODB; INSERT INTO student_demo(sname) VALUES (\'张三\');
1：并发访问事务问题
Ⅰ：脏写（Dirty Write）
事务A修改了事务B未提交的事务数据，且事务A修改的是事务B修改过的数据，这就意味着发生了脏写现象。
事务A和事务B各开启了一个事务，事务B中的事务先将sid列为1的记录的sname列更新为\'李四\'，然后事务A中的事务接着又把这条sid列
为1的记录的sname列更新为\'麻子\'并提交事务。但之后事务B中的事务进行了回滚，那么事务A中的更新也将不复存在，这种现象就称之为
脏写。这时事务A中的事务就没有效果了，明明把数据更新了，最后也提交事务了，但看到的数据什么变化也没有。
Ⅱ：脏读（Dirty Read）
事务A读取到事务B未提交的事务修改过的数据，这就意味着发生了脏读现象。
事务A和事务B各开启了一个事务，事务B中的事务先将sid列为1的记录的sname列更新为\'李四\',然后事务A中的事务再去查询这条sid为1
的记录，如果读到列sname的值为\'李四\'，而事务B中的事务稍后进行了回滚，那么事务A中的事务相当于读到了一个不存在的数据，这种现
象就称之为脏读。
Ⅲ：不可重复读（Non-Repeatable Read）
事务A修改了事务B未提交事务读取的数据，这就意味着会发生不可重复的现象。
我们在事务B中提交了几个隐式事务(注意是隐式事务, 意味着语句结束事务就提交了)，这些事务都修改了sid列为1的记录的列sname的
值，每次事务提交之后，如果事务A中的事务都可以查看到最新的值，这种现象也被称之为不可重复读。
Ⅳ：幻读（Phantom）
事务A根据某些搜索条件查询出了一些记录，但事务A并没有提交，这时事务B写了一些符合之前事务A查询的搜索条件数据，并提交了事务B，
这时事务A再次执行查询条件时发现记录变多了，这就意味着发生了幻读；
注：这里的事务B写入数据（这里的写入可以指INSERT、UPDATE操作）
事务A中的事务先根据sid<5的条件查询表student_demo得到了sname列值为\'张三\'的记录；之后事务B提交了一个隐式事务，该事务向表
student_demo中插入了一条新记录；之后事务A中的事务再根据相同的条件sid<5查询表student_demo，得到的结果集中包含了事务B中
的事务新插入的那条记录，这种现象也被称之为幻读。我们把新插入的那些记录称之为幻影记录。
注意（幻读问题）:
①：如果事务B中删除了一些些符合sid<5的记录而不是插入新记录，那事务A之后再根据sid<5的条件读取的记录变少了，这种现象不属于
幻读，幻读强调的是一个事务按照某个相同条件多次读取记录时，后读取时读到了之前没有读到的记录。
②：那对于先前已经读到的记录，之后又读取不到这种情况，这相当于对每一条记录都发生了不可重复读的现象。幻读只是重点强调了读取
到了之前读取没有获取到的记录。
补充：幻读发生在INSERT和DELETE，为什么这么说（幻读发生条件“未提交的事务A中，第二次读取比第一次读取记录增多了”）：
如事务B直接INSERT添加了一条记录，并符合查询条件的，而事务A查询数据记录多了，这构成幻读；那其它事务更改了一条记录，把
记录的条件字段改成了符合事务A查询的条件，这导致了事务A查询时数据记录也多了，这也构成幻读；
反正我们知道幻读是"未提交的事务A中，第二次读取比第一次读取记录增多了"就行了。
关于《A Critique of ANSI SQL Isolation Levels》给出幻读在INSERT、DELETE、UPDATE中均可能发生
2：SQL中的四种隔离级别
上面介绍了几种并发事务执行过程中可能遇到的一些问题，这些问题有轻重缓急之分，我们给这些问题按照严重性来排一下序：脏写 > 脏读 > 不可重复读 > 幻读
我们愿意舍弃一部分隔离性来换取一部分性能，在这里就体现在：设立一些隔离级别，隔离级别越低，并发问题发生的就越多。
SQL标准中设立了4个隔离级别:
① READ UNCOMMITTED（读未提交）：
在该隔离级别，所有事务都可以看到其它未提交事务的执行结果。不能避免脏读、幻读、不可重复读。
② READ COMMITTED（读已提交）：
它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这是大多数数据库系统的默认隔离级别(但不是MySQL默认的)。
可以避免脏读，但幻读、不可重复读问题仍然存在。这时Oracle隔离级别
③ REPEATABLE READ（可重复读）：
事务A在读到一条数据之后，此时事务B对该数据进行了修改并提交，那么事务A再读该数据，读到的还是原来的内容。
可以避免脏读、不可重复读，但幻读问题仍然存在。这是MySQL的默认隔离级别。
④ SERIALIZABLE（可串行化）：
确保事务可以从一个表中读取相同的行。在这个事务持续期间，禁止其它事务对该表执行插入、更新和删除操作。所有的并发问题都可
以避免，但性能十分低下。能避免脏读、不可重复读和幻读。
比如：事务A和事务B都开启了事务，假设事务A对第三行数据进行了操作，那么事务B将无法对事务A的第三行数据进行操作
注：脏写这个问题太严重了，不论是哪种隔离级别，都不允许脏写的情况发生。
SQL标准中规定，针对不同的隔离级别，并发事务可以发生不同严重程度的问题,具体情况如下:
| 隔离级别（性能从高到低） | 脏读可能性 | 不可重复的可能性 | 幻读可能性 | 加锁读 |
| READ UNCOMMITTED（读未提交） | √ | √ | √ | X |
| READ COMMITTED （读已提交） | X | √ | √ | X |
| REPEATABLE READ （可重复读） | X | X | √ | X |
| SERIALIZABLE （可串行化） | X | X | X | √ |
3：MySQL支持的四种隔离级别及设置
不同的数据库厂商对SQL标准中规定的四种隔离级别支持不一样。比如Oracle就只支持READ COMMITTED (默认隔离级别)和SERIALIZABLE隔离级别。MySQL虽然支持4种隔离级别，但与SQL标准中所规定的各级隔离级别允许发生的问题却有些出入，MySQL在REPEATABLE READ隔离级别下，是可以禁止幻读问题的发生的，禁止幻读的原因在后面将详解。MySQL的默认隔离级别为REPEATABLE READ，我们也是可以手动修改一下事务的隔离级别。
查看隔离级别： SHOW VARIABLES LIKE \'tx_isolation\'; + | Variable_name | Value | + | tx_isolation | REPEATABLE-READ | + SHOW VARIABLES LIKE \'transaction_isolation\'; + | Variable_name | Value | + | transaction_isolation | REPEATABLE-READ | + SELECT @@GLOBAL.transaction_isolation; SELECT @@SESSION.transaction_isolation; 设置事务的隔离级别： SET [GLOBAL|SESSION] TRANSACTION ISOLATION LEVEL 隔离级别; MySQL四种可选隔离级别：READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE SET [GLOBAL|SESSION] TRANSACTION_ISOLATION = \'隔离级别\' MySQL四种可选隔离级别：READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE 补充：在设置事务隔离级别的语句中，在SET关键字后面可以放置GLOBAL、SESSION或者什么都不放，这样会对不同范围的事务产生不 同的影响，具体如下： Ⅰ：使用GLOBAL关键字(在全局范围产生影响): 如：SET GLOBAL TRANSACTION_ISOLATION = \'SERIALIZABLE\'; ①：只对执行完该语句之后新产生的会话起作用； ②：当前已经存在的会话无效。 Ⅱ：使用SESSION关键字(在会话范围产生影响): 如：SET SESSION TRANSACTION_ISOLATION = \'SERIALIZABLE\'; ①：对当前会话所有的后续事务有效; ②：该语句可以在已经开启的事务中执行，但不会影响当前正在执行的事务; ③：如果在事务之间执行，则对后续的事务有效。 Ⅲ：上述两个关键字都不使用(只对执行SET语句后的下一个事务产生影响): 如：SET TRANSACTION_ISOLATION = \'SERIALIZABLE\'; ①：只对当前会话中下一个即将开启的事务有效； ②：下一个事务执行完后，后续事务将恢复到之前的隔离级别； ③：该语句不能在已经开启的事务中执行，否则报错。
.
作者：蚂蚁小哥
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须在文章页面给出原文链接，否则保留追究法律责任的权利。
以上是关于MySQL事务基础知识的主要内容，如果未能解决你的问题，请参考以下文章