mysql脏读怎么解决 mysql脏读幻读重复读

详解MySQL（InnoDB）如何处理死锁

锁是需要事务结束后才释放的。

一个是 MVCC，一个是两阶段锁协议。

为什么要并发控制呢？是因为多个用户同时操作 MySQL 的时候，为了提高并发性能并且要求如同多个用户的请求过来之后如同串行执行的一样（为了解决脏读、不可重复读、幻读）

官方定义：

两阶段锁协议是指所有事务必须分两个阶段对数据加锁和解锁，在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁；在释放一个封锁之后，事务不再申请和获得任何其他封锁。

对应到 MySQL 上分为两个阶段：

但是两阶段锁协议不要求事务必须一次将所有需要使用的数据加锁（innodb在需要的索引列数据才锁行），并且在加锁阶段没有顺序要求，所以这种并发控制方式会形成死锁。

MySQL有两种死锁处理方式：

死锁检测 （默认开启）

死锁检测的原理是构建一个以事务为顶点、锁为边的有向图，判断有向图是否存在环，存在即有死锁。

回滚

检测到死锁之后，选择插入更新或者删除的行数最少的事务回滚，基于 INFORMATION_SCHEMA.INNODB_TRX 表中的 trx_weight 字段来判断。

收集死锁信息：

减少死锁：

死锁解决：

mysql数据库问题，谢谢大神，在线等！！！！

哇，别念了，课本上原原本本写出来的吧，不喜欢就别进这一行

MYSQL实战优化——事务、undo log版本链

今天我们来看看多个事务对缓存页里的同一条数据同时进行更新或者查询，此时会产生哪些问题？这里实际会涉及到 脏写、脏读、不可重复读、幻读， 四中问题。

这个脏写的话，它的意思是说有两个事务，事务A和事务B同时在更新一条数据，事务A先把它更新为A值，事务B紧接着就把它更新为B值。事务A是先更新的，它在更新之前，这行数据的值为NULL，所以此时事务A的undo log日志大概是这样的：更新之前这行数据的值为NULL，主键为XX 。

那么此时事务B更新完了数据的值为B，结果此时事务A突然回滚了，那么就会用它的undo log日志去回滚。此时事务A一回滚，直接就会把那行数据的值更新回之前的NULL值。所以对于事务B看到的场景，就是自己明明更新了，结果值却没了，这就是 脏写。

假设事务A更新了一行数据的值为A，此时事务B去查询了一些这行数据的值，看到的值是A，然后事务B拿着刚查询到的A值去处理各种业务。但是此时不幸的事情发生了，事务A突然回滚了，导致它刚才更新的A值没了，此时那行数据的值回滚为NULL值。这就是所谓的 脏读。 它的本质是事务B去查询了事务A修改过的数据，但是此时事务A还没有提交，事务A随时会回滚导致事务B查询了一个不存在的值。

接着我们来看一下 的问题，假设我们有一个事务A开启了，在这个事务A里会多次对一条数据进行查询。然后另外有两个事务，一个是事务B，一个是事务C，它们都是对一条数据进行更新的。假设缓存页里一条数据原来的值是A值，此时事务A开启之后，第一次查询这条数据，读取到的是A值。接着事务B更新了那行数据的值为B，同时提交事务，然后事务A第二次查询该行数据，此时查到的是事务B修改过的值B 。接着事务C更新了那行数据的值为C，同时提交事务，然后事务A第三次查询该行数据，此时查到的是事务C修改过的值C值。

那么上面的场景有什么问题呢？其实要说没问题也是可以的，毕竟事务B和C都提交事务了。但是要说有问题也是可以的，就是事务A可能第一次查询到的是A值，那么它可能希望的是在事务执行期间，如果多次查询数据，都是同样的一个A值。但是该场景下，A值明显不是可重复读的。

这种情况算不算一个问题呢？其实这是根据你的业务决定的。有的业务要的是可重复读，而有的业务却需要不可重复读。

假设一个事务A先发送一条SQL语句，里面有一个条件，要查询一批数据出来，比如“select * from table where id 10”，类似这种SQL，它一开始查询出了10条数据。然后事务B往表里插入了几条数据，而且事务B还提交了。此时事务A再次查询，由于事务B插入了几条数据，导致这次它查询出来了12条数据。同样的SQL语句，两次的查询结果却不一样，所以开始怀疑自己是不是出现了幻觉？导致刚才幻读了？这就是幻读一词的由来。

在SQL标准中规定了4种事务隔离级别，就是说多个事务并发运行的时候，互相是如何隔离的，从而避免一些事务并发问题。这4种级别包括了： read uncommitted(读未提交)、read committed(读已提交)、repeatable read(可重复读)、serializable(串行化) 。

第一个read uncommitted隔离级别是不允许发生脏写的。也就是说，不可能两个事务在没提交的情况下去更新同一行数据的值，但是在这种隔离级别下，可能发生脏读、不可重复读、幻读。所以一般来说，是没有人做系统开发的时候把事务隔离级别设置为读未提交这个级别的。

第二个是read committed隔离级别，也就是俗称的RC级别，这个级别不会发生脏写和脏读。也就是说，别的事务没提交的情况下修改的值，你是绝对读不到的。但是，可能会发生不可重复读和幻读问题。

第三个是repeatable read隔离级别，也就是俗称的RR级别，就是可重复读级别。这个级别下，不会发生脏写、脏读、不可重复读的问题。事务一旦开启，多次查询一个值，会一直读到同一个值。但是它会发生幻读的问题。

最后一个隔离级别，就是serializable级别，这种级别，根本不允许多个事务并发执行，只能串行执行，所以不可能有幻读问题。但是这种级别一般除非脑子坏了，否则不可能设置这种级别。

MySQL默认设置的事务隔离级别都是RR级别的，而且MySQL的RR级别是可以避免幻读发生的。

下面的命令可以修改MySQL的默认事务隔离级别：

另外，给大家一个彩蛋，假设你在开发业务系统的时候，比如用spring里的@Transaction注解来做事务这块，假设某个事务你就是有点手痒，想搞成RC级别，那么没问题，在@Transaction注解里是有一个isolation参数的，里面是可以设置事务隔离级别的，具体的设置方式如下：

@Transaction(isolation=Isolation.DEFAULT),默认的就是DEFAULT值，这个就是MySQL默认支持什么隔离就是什么隔离级别。但是你可以手动改成其它的隔离级别，比如，isolation = Isolation.READ_COMMITTED级别，此时你就可以读取到其它事务已提交的数据。

简单来说，我们每条数据其实都有两个隐藏字段，一个是trx_id，一个是roll_pointer，这个trx_id就是最近一次更新这条数据的事务id，roll_pointer就是指向了你更新这个事务之前生成的undo log，关于undo log之前都讲过了。

举个例子，假设有一个事务A（id=50），插入了一条数据，那么此时这条数据的隐藏字段以及指向的undo log如下图所示：

插入的这条数据的值是A，因为事务A的id是50，所以这条数据的trx_id就是50，roll_pointer指向一个空的undo log，因为之前这条数据是没有的。接着有一个事务B修改了一下这条数据，把值改成了B，事务B的id是58，那么此时更新之前会生成一个undo log记录之前的值，然后会让roll_pointer指向这个实际的undo log回滚日志，如下图所示：

MySQL知识点总结

只要字段值还可以继续拆分，就不满足第一范式。

范式设计得越详细，对某些实际操作可能会更好，但并非都有好处，需要对项目的实际情况进行设定。

在满足第一范式的前提下，其他列都必须完全依赖于主键列。 如果出现不完全依赖，只可能发生在联合主键的情况下：

实际上，在这张订单表中，product_name 只依赖于 product_id ，customer_name 只依赖于 customer_id。也就是说，product_name 和 customer_id 是没用关系的，customer_name 和 product_id 也是没有关系的。

这就不满足第二范式：其他列都必须完全依赖于主键列！

拆分之后，myorder 表中的 product_id 和 customer_id 完全依赖于 order_id 主键，而 product 和 customer 表中的其他字段又完全依赖于主键。满足了第二范式的设计！

在满足第二范式的前提下，除了主键列之外，其他列之间不能有传递依赖关系。

表中的 customer_phone 有可能依赖于 order_id 、 customer_id 两列，也就不满足了第三范式的设计：其他列之间不能有传递依赖关系。

修改后就不存在其他列之间的传递依赖关系，其他列都只依赖于主键列，满足了第三范式的设计！

查询每门课的平均成绩。

查询 score 表中至少有 2 名学生选修，并以 3 开头的课程的平均分数。

分析表发现，至少有 2 名学生选修的课程是 3-105 、3-245 、6-166 ，以 3 开头的课程是 3-105 、3-245。也就是说，我们要查询所有 3-105 和 3-245 的 degree 平均分。

查询所有学生的 name，以及该学生在 score 表中对应的 c_no 和 degree 。

通过分析可以发现，只要把 score 表中的 s_no 字段值替换成 student 表中对应的 name 字段值就可以了，如何做呢？

查询所有学生的 no 、课程名称 ( course 表中的 name ) 和成绩 ( score 表中的 degree ) 列。

只有 score 关联学生的 no ，因此只要查询 score 表，就能找出所有和学生相关的 no 和 degree ：

然后查询 course 表：

只要把 score 表中的 c_no 替换成 course 表中对应的 name 字段值就可以了。

查询所有学生的 name 、课程名 ( course 表中的 name ) 和 degree 。

只有 score 表中关联学生的学号和课堂号，我们只要围绕着 score 这张表查询就好了。

只要把 s_no 和 c_no 替换成 student 和 srouse 表中对应的 name 字段值就好了。

首先把 s_no 替换成 student 表中的 name 字段：

再把 c_no 替换成 course 表中的 name 字段：

查询 95031 班学生每门课程的平均成绩。

在 score 表中根据 student 表的学生编号筛选出学生的课堂号和成绩：

这时只要将 c_no 分组一下就能得出 95031 班学生每门课的平均成绩：

查询在 3-105 课程中，所有成绩高于 109 号同学的记录。

首先筛选出课堂号为 3-105 ，在找出所有成绩高于 109 号同学的的行。

查询所有成绩高于 109 号同学的 3-105 课程成绩记录。

查询所有和 101 、108 号学生同年出生的 no 、name 、birthday 列。

查询 '张旭' 教师任课的学生成绩表。

首先找到教师编号：

通过 sourse 表找到该教师课程号：

通过筛选出的课程号查询成绩表：

查询某选修课程多于5个同学的教师姓名。

首先在 teacher 表中，根据 no 字段来判断该教师的同一门课程是否有至少5名学员选修：

查看和教师编号有有关的表的信息：

我们已经找到和教师编号有关的字段就在 course 表中，但是还无法知道哪门课程至少有5名学生选修，所以还需要根据 score 表来查询：

根据筛选出来的课程号，找出在某课程中，拥有至少5名学员的教师编号：

在 teacher 表中，根据筛选出来的教师编号找到教师姓名：

查询 “计算机系” 课程的成绩表。

思路是，先找出 course 表中所有 计算机系 课程的编号，然后根据这个编号查询 score 表。

查询 计算机系 与 电子工程系 中的不同职称的教师。

查询课程 3-105 且成绩 至少 高于 3-245 的 score 表。

查询课程 3-105 且成绩高于 3-245 的 score 表。

查询某课程成绩比该课程平均成绩低的 score 表。

查询所有任课 ( 在 course 表里有课程 ) 教师的 name 和 department 。

查询 student 表中至少有 2 名男生的 class 。

查询 student 表中不姓 "王" 的同学记录。

查询 student 表中每个学生的姓名和年龄。

查询 student 表中最大和最小的 birthday 值。

以 class 和 birthday 从大到小的顺序查询 student 表。

查询 "男" 教师及其所上的课程。

查询最高分同学的 score 表。

查询和 "李军" 同性别的所有同学 name 。

查询和 "李军" 同性别且同班的同学 name 。

查询所有选修 "计算机导论" 课程的 "男" 同学成绩表。

需要的 "计算机导论" 和性别为 "男" 的编号可以在 course 和 student 表中找到。

建立一个 grade 表代表学生的成绩等级，并插入数据：

查询所有学生的 s_no 、c_no 和 grade 列。

思路是，使用区间 ( BETWEEN ) 查询，判断学生的成绩 ( degree ) 在 grade 表的 low 和 upp 之间。

准备用于测试连接查询的数据：

分析两张表发现，person 表并没有为 cardId 字段设置一个在 card 表中对应的 id 外键。如果设置了的话，person 中 cardId 字段值为 6 的行就插不进去，因为该 cardId 值在 card 表中并没有。

要查询这两张表中有关系的数据，可以使用 INNER JOIN ( 内连接 ) 将它们连接在一起。

完整显示左边的表 ( person ) ，右边的表如果符合条件就显示，不符合则补 NULL 。

完整显示右边的表 ( card ) ，左边的表如果符合条件就显示，不符合则补 NULL 。

完整显示两张表的全部数据。

在 MySQL 中，事务其实是一个最小的不可分割的工作单元。事务能够 保证一个业务的完整性 。

比如我们的银行转账：

在实际项目中，假设只有一条 SQL 语句执行成功，而另外一条执行失败了，就会出现数据前后不一致。

因此，在执行多条有关联 SQL 语句时， 事务 可能会要求这些 SQL 语句要么同时执行成功，要么就都执行失败。

在 MySQL 中，事务的 自动提交 状态默认是开启的。

自动提交的作用 ：当我们执行一条 SQL 语句的时候，其产生的效果就会立即体现出来，且不能 回滚 。

什么是回滚？举个例子：

可以看到，在执行插入语句后数据立刻生效，原因是 MySQL 中的事务自动将它 提交 到了数据库中。那么所谓 回滚 的意思就是，撤销执行过的所有 SQL 语句，使其回滚到 最后一次提交 数据时的状态。

在 MySQL 中使用 ROLLBACK 执行回滚：

由于所有执行过的 SQL 语句都已经被提交过了，所以数据并没有发生回滚。那如何让数据可以发生回滚？

将自动提交关闭后，测试数据回滚：

那如何将虚拟的数据真正提交到数据库中？使用 COMMIT :

事务的实际应用 ，让我们再回到银行转账项目：

这时假设在转账时发生了意外，就可以使用 ROLLBACK 回滚到最后一次提交的状态：

这时我们又回到了发生意外之前的状态，也就是说，事务给我们提供了一个可以反悔的机会。假设数据没有发生意外，这时可以手动将数据真正提交到数据表中：COMMIT 。

事务的默认提交被开启 ( @@AUTOCOMMIT = 1 ) 后，此时就不能使用事务回滚了。但是我们还可以手动开启一个事务处理事件，使其可以发生回滚：

仍然使用 COMMIT 提交数据，提交后无法再发生本次事务的回滚。

事务的四大特征：

事务的隔离性可分为四种 ( 性能从低到高 ) ：

查看当前数据库的默认隔离级别：

修改隔离级别：

测试 READ UNCOMMITTED ( 读取未提交 ) 的隔离性：

由于小明的转账是在新开启的事务上进行操作的，而该操作的结果是可以被其他事务（另一方的淘宝店）看见的，因此淘宝店的查询结果是正确的，淘宝店确认到账。但就在这时，如果小明在它所处的事务上又执行了 ROLLBACK 命令，会发生什么？

这就是所谓的 脏读 ，一个事务读取到另外一个事务还未提交的数据。这在实际开发中是不允许出现的。

把隔离级别设置为 READ COMMITTED ：

这样，再有新的事务连接进来时，它们就只能查询到已经提交过的事务数据了。但是对于当前事务来说，它们看到的还是未提交的数据，例如：

但是这样还有问题，那就是假设一个事务在操作数据时，其他事务干扰了这个事务的数据。例如：

虽然 READ COMMITTED 让我们只能读取到其他事务已经提交的数据，但还是会出现问题，就是 在读取同一个表的数据时，可能会发生前后不一致的情况。* 这被称为* 不可重复读现象 ( READ COMMITTED ) 。

将隔离级别设置为 REPEATABLE READ ( 可被重复读取 ) :

测试 REPEATABLE READ ，假设在两个不同的连接上分别执行 START TRANSACTION :

当前事务开启后，没提交之前，查询不到，提交后可以被查询到。但是，在提交之前其他事务被开启了，那么在这条事务线上，就不会查询到当前有操作事务的连接。相当于开辟出一条单独的线程。

无论小张是否执行过 COMMIT ，在小王这边，都不会查询到小张的事务记录，而是只会查询到自己所处事务的记录：

这是 因为小王在此之前开启了一个新的事务 ( START TRANSACTION ) * ，那么* 在他的这条新事务的线上，跟其他事务是没有联系的 ，也就是说，此时如果其他事务正在操作数据，它是不知道的。

然而事实是，在真实的数据表中，小张已经插入了一条数据。但是小王此时并不知道，也插入了同一条数据，会发生什么呢？

报错了，操作被告知已存在主键为 6 的字段。这种现象也被称为 幻读，一个事务提交的数据，不能被其他事务读取到 。

顾名思义，就是所有事务的 写入操作 全都是串行化的。什么意思？把隔离级别修改成 SERIALIZABLE :

还是拿小张和小王来举例：

此时会发生什么呢？由于现在的隔离级别是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假设把所有的事务都放在一个串行的队列中，那么所有的事务都会按照 固定顺序执行 ，执行完一个事务后再继续执行下一个事务的 写入操作 ( 这意味着队列中同时只能执行一个事务的写入操作 ) 。

根据这个解释，小王在插入数据时，会出现等待状态，直到小张执行 COMMIT 结束它所处的事务，或者出现等待超时。

转载：

Mysql：RR隔离级别下的幻读

众所周知，Mysql在InnoDB下有四种隔离级别：

未提交读（Read Uncommitted）

提交后读（Read Committed）

可重复读（Repeatable Read）

串行化（Serializable）

其中可重复读（RR）可以避免脏读（ a事务读到b事务回滚前的数据）以及可不重复读（ a事务在b事务修改提交的前后，两次分别读到的数据不一致）。但是对于幻读（a事务在b事务insert提交前后，两次分别读到的数据不一致），却存在争议。

下面我们来做一个试验：

对于下面这张简单的数据表

id        num

1         11

2         22

3         33

我们开启a、b两个事务

a事务                b事务

begin                begin

select * from tb    ----

----                    insert into tb (id,num)values(4,44)

----                    commit

select * from tb    ----

commit

试验结果：a事务的两次select查询到的结果相同，在后一次查询中没有返回新插入id=4的那条记录。

据此，很多人判断说RR隔离级别下“不存在”幻读。

但果真如此吗？----

出现上面的试验结果，是因为在RR隔离级别事务下，Mysql会对前一次select的结果快照。所以第二次select其实是快照读（这也正是RR隔离级别下能够避免不可重复读的策略）。

如果我们把试验条件稍作修改，同样开启a、b两个事务：

a事务                b事务

begin                begin

select * from tb    ----

----                    insert into tb (id,num)values(5,55)

----                    commit

update tb set num=num+1    ----        #此处a事务做一次修改操作

select * from tb    ----

commit

试验结果：在a事务的第二次select中出现了b事务新插入的id=5的记录。

由于做了update操作，之前的快照失效了，所以说RR隔离级别下的快照策略并没能真正避免幻读。

ps. 假如给第二次的select查询上锁（无论是共享锁还是排它锁），也会得到同样的结果，都会令快照失效。

关于mysql脏读怎么解决和mysql脏读幻读重复读的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。