关于在MySQL同一事务中先更新再查询,结果是更新后的数据问题

问题出现场景:
java 代码在同一个事务中先执行update 再执行select 发现select 的数据是update之后的结果,此时事务还没有提交,直接查询数据库,数据库的数据还没有发生变更.

问题出现原因:
在数据库事务是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行,这是一种机制,用以维护数据库的完整性。在你这个事务单元中存在两个操作,一个是update,一个是select;你前面的update执行成功了,再执行select肯定能够查询到前面update的数据,因为你是在一个单元中。但是另外一个事务(即另一个单元)则不能select到这个update的数据,因为你update的数据还没提交,只在该单元中有效;

注意: 此处要与脏读区分开,脏读所指的读到了未提交的数据(这是两个事务操作,而本文的问题前提是在同一个事务中)。也就是说,一个事务正在对一条记录做修改,在这个事务完成并提交之前,这条数据是处于待定状态的(可能提交也可能回滚),这时,第二个事务来读取这条没有提交的数据,并据此做进一步的处理,就会产生未提交的数据依赖关系。这种现象被称为脏读。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 在 MySQL 中,行锁和表锁的锁定级别是不同的。行锁的锁定级别比表锁低,因此在同一事务内先加行锁再加表锁是不会冲突的。 当一个事务对行加锁时,该事务对其他事务的影响仅限于该行,其他事务可以继续访问其他行。而表锁则会锁定整张表,其他事务将无法访问该表中的任何行。因此,在同一事务内先加行锁再加表锁不会冲突,因为行锁的锁定范围要小于表锁。 ### 回答2: 在MySQL中,行锁和表锁是用来控制多个事务同一数据资源进行访问和修改的方式。行锁是在数据行级别上进行的锁定,而表锁是在整个表级别上进行的锁定。 当在同一事务内先加行锁再加表锁时,并不会发生冲突的原因是锁的粒度不同。行锁只会锁定特定的行,而表锁则会锁定整个表。事务在执行时,会按照顺序先获取行锁,再获取表锁。 假设有两个事务T1和T2都要对同一表进行操作,其中T1先获取到了行锁,然后进行相应的操作。在T1未释放行锁之前,T2无法获取到行锁,因此也无法进行操作,避免了冲突的发生。 而在T1释放了行锁之后,T1将获取到表锁,然后进行相应的操作。此时,T2再次进行操作时,会发现表锁已经被T1获取了,无法继续进行操作,也就避免了冲突的发生。 因此,通过先加行锁再加表锁的方式,可以保证同一事务内对同一数据资源的操作不会发生冲突。这是因为行锁和表锁的不同粒度,行锁在事务执行期间保证了行级别的独占性,而表锁在事务结束时进行申请,保证了操作的顺序性和互斥性。 ### 回答3: 在 MySQL 中,行锁和表锁是用来保证事务并发执行时数据一致性的机制。 行锁是针对一个具体的数据行加锁,只有在需要修改或读取该行数据时才会加锁。行锁的粒度更细,所以能够允许更多的并发访问。当一个事务要加行锁时,会先检查该行是否已经被其他事务加了行锁,如果已经加锁,则需要等待其他事务释放锁才能继续执行。 表锁是针对整张表加锁,当一个事务要加表锁时,会先检查该表是否已经被其他事务加了锁,如果已经加锁,则需要等待其他事务释放锁才能继续执行。表锁的粒度比行锁大,所以在加锁时需要锁定更多的资源,而且会导致并发性能下降。 当一个事务内先加行锁再加表锁时,是因为行锁和表锁的加锁顺序是互相兼容的。事务在加行锁时只会锁定具体的数据行,不会涉及到整张表的锁定。而在加表锁时,只需要锁定整张表,不会涉及具体的数据行。由于行锁和表锁的粒度是不同的,所以在加锁时不会产生冲突。 因此,当一个事务先加行锁再加表锁时,由于行锁和表锁的粒度不同,所以不会发生冲突。这样可以保证事务在并发执行时能够正确地读取和修改数据,并且能够保持数据的一致性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值