记录select for update mysql 死锁问题

最新推荐文章于 2024-01-25 16:40:02 发布
最新推荐文章于 2024-01-25 16:40:02 发布
阅读量4.4k 收藏 13
点赞数 3
分类专栏： java mysql 文章标签： mysql 死锁
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/songkai558919/article/details/119005612
版权
java 同时被 2 个专栏收录
48 篇文章 1 订阅
订阅专栏
mysql
9 篇文章 0 订阅
订阅专栏

背景

项目要求某表单个列自增，但是where条件，并不是这个列所有的值都符合自增

想用select for update mysql 锁表后，查询最大值自增，后发现有死锁问题，先记录一下。

 tag_id自增

自增sql where条件

原版sql如下

INSERT INTO  表一(
            column1, 
            column2, 
            column3, 
            column4,
            age
        )SELECT
            column1, 
            column2, 
            column3, 
            column4,
            (select IFNULL((select max(age) from 表名,0)+1);

INSERT INTO  place_tag(
            `tagkey_id`, 
            `tagkey_name`, 
             `tag_id`, 
            `tag`,
            `status`,
            `tag_type`,
            `type_name`
        )SELECT
           `tagkey_id`, 
            `tagkey_name`, 
             （(SELECT IFNULL((SELECT max(tag_id) FROM place_tag,0)+1, 
            `tag`,
            `status`,
            `tag_type`,
            `type_name`
            ) WHERE `tagkey_id` = '119001' AND STATUS != 3;

实例

以下代码在可重复读隔离级别下执行，表中原来只有1~10的rank。假如A、B两个事务同时试图插入rank为21和22的rank；

@Transactional
    public void createBannerDeadlock(Banner banner) {
        banner.recordCreate();
        List<Banner> rankList = cscCenterBannerDAO.selectForUpdate(banner.getRank());
        // 无记录,A占据间隙锁rank(10,+), B占据间隙锁 (10,+)，gap锁之间不互斥
        if (!rankList.isEmpty()) {
            throw new RuntimeException("记录已存在");
        }
        try {
            logger.info("睡5秒钟");
            Thread.sleep(MILLIS);
        } catch (InterruptedException e) {
            throw new RuntimeException("中断");
        }
        logger.info("开始插入: {}", System.currentTimeMillis());
        cscCenterBannerDAO.insert(banner); // 都申请插入意向锁, 都需要等待别人的间隙锁释放；死锁
    }

1.如果rank上没索引:
两个事务第一个for update就会互相阻塞(锁全表)，串行执行，没有死锁，两个插入都成功；
2.如果rank上有索引(普通索引或者唯一索引):
两个事务第一个for update不会互相阻塞(锁区间10~正无穷)，并行执行，有死锁，到最后真正插入的时候，两者都需要插入意向锁，然后都等待对方的gap锁释放，死锁；等待很久以后，一个成功一个失败(一个事务被回滚)；

死锁异常:

Deadlock found when trying to get lock; try restarting transaction;

原理

两个原因导致了有索引的时候反而会死锁:
1.select for update的间隙锁之间不互斥,两个事务都能获得gap锁;
2.插入意向锁需要等待gap锁释放;

间隙锁相关: http://xiaoyue26.github.io/2018/05/26/2018-05/MVCC%E4%B8%8E%E9%97%B4%E9%9A%99%E9%94%81-mysql%E6%8B%BE%E9%81%97/
意向锁相关: http://xiaoyue26.github.io/2018/12/24/2018-12/mysql%E6%84%8F%E5%90%91%E9%94%81/

select for update的结果

即使是同样的语句，也有可能有不同的加锁结果。
1.如果有唯一索引,命中了唯一记录: 行锁,互斥锁;
2.如果有唯一索引,没命中: gap锁，另一个事务也可以获得这个gap锁，但是不能插入数据；(后续有死锁可能)
3.如果有普通索引,命中了记录: 行锁+gap锁;(后续有死锁可能)
4.如果有普通索引,没有命中记录: gap锁,和情况2相同;(后续有死锁可能)
5.如果没有索引,直接锁全表，互斥，直接阻塞别的事务。（mysql的行锁是依赖索引的，这一点和oracle锁在数据块上不同；
因此如果没有索引或者没有用上索引，mysql就只能加表锁了。）

可见如果where条件没有命中记录的时候,如果有索引，反而可能有死锁风险。
除了select for update,其他进行当前读的语句(如delete)也可以获得gap锁，因此也有同样的烦恼。

那么都有哪些语句能获得gap锁呢？

参考

https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-gap-locks

gap锁

首先当然要可重复读和串行读才有gap锁。
然后根据上面的参考资料，gap锁只有一个目标:
就是防止别的事务在这个区间插入数据。

因此不同事务可以获得同一个区间的gap锁，因为这与上述目标并不冲突。两个事务可以获得这个区间的gap-S锁，gap-X锁，都可以。这一点和意向锁有点类似，只不过意向锁是加在表上的，gap锁是加在区间上的。

gap-S锁和gap-X锁没有区别。(因此select in share mode和select for update获得的gap锁本质是一样的，想要无锁读，就直接用select进行快照读。)

select in share mode/select for update/update/delete这4种语句是可能获取gap锁的。因此这4种当前读如果没有命中记录，而且又用到了索引，就会给死锁埋下风险。

当可以通过select for update的where条件筛出记录时，上面的代码是不会有deadlock问题的。然而当select for update中的where条件无法筛选出记录时，这时在有多个线程执行上面的acquire方法时是可能会出现死锁的。

2.1 一个简单的复现场景

下面通过一个比较简单的例子复现一下这个场景
首先给表里初始化3条数据。

insert into number select 'bbb',2;
insert into number select 'hhh',8;
insert into number select 'yyy',25;

接着按照如下的时序进行操作：

session 1session 2
begin;
begin;
select * from number where prefix='ddd' for update;
select * from number where prefix='fff' for update
insert into number select 'ddd',1
锁等待中insert into number select 'fff',1
锁等待解除死锁，session 2的事务被回滚

2.2 分析下这个死锁

通过查看show engine innodb status的信息，我们慢慢地观察每一步的情况：

2.2.1 session1做了select for update

------------
TRANSACTIONS
------------
Trx id counter 238435
Purge done for trx's n:o < 238430 undo n:o < 0 state: running but idle
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281479459589696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 281479459588792, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 238434, ACTIVE 3 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 160, OS thread handle 123145573965824, query id 69153 localhost root
TABLE LOCK table test.number trx id 238434 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;

事务238434拿到了hhh前的gap锁，也就是('bbb', 'hhh')的gap锁。

2.2.2 session2做了select for update

------------
TRANSACTIONS
------------
Trx id counter 238436
Purge done for trx's n:o < 238430 undo n:o < 0 state: running but idle
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281479459589696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 238435, ACTIVE 3 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 161, OS thread handle 123145573408768, query id 69155 localhost root
TABLE LOCK table test.number trx id 238435 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238435 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
---TRANSACTION 238434, ACTIVE 30 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 160, OS thread handle 123145573965824, query id 69153 localhost root
TABLE LOCK table test.number trx id 238434 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;

事务238435也拿到了hhh前的gap锁。

截自InnoDB的lock_rec_has_to_wait方法实现，可以看到的LOCK_GAP类型的锁只要不带有插入意向标识，不必等待其它锁（表锁除外）

2.2.3 session1尝试insert

------------
TRANSACTIONS
------------
Trx id counter 238436
Purge done for trx's n:o < 238430 undo n:o < 0 state: running but idle
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281479459589696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 238435, ACTIVE 28 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 161, OS thread handle 123145573408768, query id 69155 localhost root
TABLE LOCK table test.number trx id 238435 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238435 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
---TRANSACTION 238434, ACTIVE 55 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 160, OS thread handle 123145573965824, query id 69157 localhost root executing
insert into number select 'ddd',1
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;

TABLE LOCK table test.number trx id 238434 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;

可以看到，这时候事务238434在尝试插入'ddd',1时，由于发现其他事务(238435)已经有这个区间的gap锁，因此innodb给事务238434上了插入意向锁，锁的模式为LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION，等待事务238435释放掉gap锁。

截取自InnoDB的lock_rec_insert_check_and_lock方法实现

2.2.4 session2尝试insert

------------------------
LATEST DETECTED DEADLOCK
------------------------
2017-12-21 22:50:40 0x70001028a000
*** (1) TRANSACTION:
TRANSACTION 238434, ACTIVE 81 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 160, OS thread handle 123145573965824, query id 69157 localhost root executing
insert into number select 'ddd',1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
*** (2) TRANSACTION:
TRANSACTION 238435, ACTIVE 54 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 161, OS thread handle 123145573408768, query id 69159 localhost root executing
insert into number select 'fff',1
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238435 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238435 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
*** WE ROLL BACK TRANSACTION (2)

TRANSACTIONS

Trx id counter 238436
Purge done for trx's n:o < 238430 undo n:o < 0 state: running but idle
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281479459589696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 281479459588792, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 238434, ACTIVE 84 sec
3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 160, OS thread handle 123145573965824, query id 69157 localhost root
TABLE LOCK table test.number trx id 238434 lock mode IX
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;
Record lock, heap no 7 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 646464; asc ddd;;
1: len 6; hex 00000003a362; asc b;;
2: len 7; hex de000001e60110; asc ;;
3: len 8; hex 8000000000000001; asc ;;
RECORD LOCKS space id 1506 page no 3 n bits 80 index uk_prefix of table test.number trx id 238434 lock_mode X locks gap before rec insert intention
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 3; hex 686868; asc hhh;;
1: len 6; hex 00000003a350; asc P;;
2: len 7; hex d2000001ff0110; asc ;;
3: len 8; hex 8000000000000008; asc ;;

到了这里，我们可以从死锁信息中看出，由于事务238435在插入时也发现了事务238434的gap锁，同样加上了插入意向锁，等待事务238434释放掉gap锁。因此出现死锁的情况。

雪中鱼01
关注
  • 3
    点赞
  • 踩
  • 13
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
mysql select for updae语句死锁_select for update引发死锁分析
weixin_29069131的博客
02-03 645
本文针对MySQL中在Repeatable Read的隔离级别下使用select for update可能引发的死锁问题进行分析。1. 案例业务中需要对各种类型的实体进行编号，例如对于x类实体的编号可能是x201712120001，x201712120002，x201712120003类似于这样。可以观察到这类编号有两个部分组成：x+日期作为前缀，以及流水号(这里是四位的流水号)。如果用数据库表实...
MySQL中的SELECT FOR UPDATE：原理、应用与优化
最新发布
My_wife_QBL的博客
06-29 1118
是MySQL中的一种行级锁定机制，它允许在事务中对查询结果集中的行进行加锁，以防止其他事务对这些行进行修改或删除。这种锁定机制通常用于确保事务的隔离性和数据的一致性，特别是在高并发环境下。
mysql for update死锁_Mysql 数据库死锁过程分析(select for update)
weixin_33441139的博客
01-18 635
近期有一个业务需求，多台机器需要同时从Mysql一个表里查询数据并做后续业务逻辑，为了防止多台机器同时拿到一样的数据，每台机器需要在获取时锁住获取数据的数据段，保证多台机器不拿到相同的数据。我们Mysql的存储引擎是innodb，支持行锁。解决同时拿数据的方法有很多，为了更加简单，不增加其他表和服务的情况下，我们考虑采用select... for update的方式，这样X锁锁住查询的数据段，表里...
mysql for update死锁_有关mysql的for update以及 死锁问题
weixin_33290540的博客
01-27 366
一、先说锁的概念锁级别：1.行级锁： InnoDB引擎(也支持表级锁，默认是行级锁)，开销大，加锁慢；会出现死锁。锁定粒度最小，发生锁冲突的概率最低，并发度最高。2.表级锁：MylSAM引擎和Memory引擎，开销小，加锁快；不会出现死锁，锁定粒度最大，发生锁冲突的概率最高，并发度最低。3.页级锁：BDB引擎(也支持表级锁)，开销和加锁时间介于行锁和表锁之间；会出现死锁；粒度也介于行锁和表锁之间，...
mysql for update 死锁问题排查
qq_40813329的博客
06-30 3425
使用姿势 加锁方式 是。当时，是如果查不到数据for update是否会加锁呢?当我们 而 不是 相等条件 检索数据 时，InnoDB 会给条件 无主键/索引，表级锁 for update 的注意点 仅适用于 ，并且，在 生效 和 区别（，） 查看当前运行的事务 杀掉 lock_wait 的事务 设置表日志 查询数据库中哪些线程正在执行MySQL中 show processlist命令详解 大量 block ，lock wait 或者 一条 sql running 很久 相关问题 其
select for update引发死锁分析
Nuan_Feng的博客
06-25 2282
问题复现 读写锁冲突 场景：4场直播同时准备作业。首先查询作业是否有这条记录。这里查询后添加写锁。 作业准备前是没有记录的，所以这里就会造成间隙锁。 假设现在只有3条数据。然后通过role查询等于4的。这里查不到数据库，就会锁住3之后的所有数据。 先营造测试环境，给xxl_job_user表role字段添加唯一索引。 执行如下命令： set @@autocommit=0; SHOW VARIABLES like ‘%autocommit%’; START transaction ; SELECT * F
select for update 引发死锁分析
thereyang的博客
06-18 2469
本文针对MySQL InnoDB中在Repeatable Read的隔离级别下使用select for update可能引发的死锁问题进行分析。 1. 业务案例 业务中需要对各种类型的实体进行编号，例如对于x类实体的编号可能是x201712120001，x201712120002，x201712120003类似于这样。可以观察到这类编号有两个部分组成：x+日期作为前缀，以及流水号（这里是四位的流水号）。 如果用数据库表实现一个能够分配流水号的需求，无外乎就可以建立一个类似于下面的表： CREATE
mysql for update 锁_mysql for update 死锁问题
weixin_32101685的博客
01-18 385
在RR条件， id是主键，插入五条数据idname1title12title23title39title910title10session 1session 2begin;begin;select * from user where id = 6 for update;~select * from user where id = 6 for updateinsert into user 6, ti...
for update 解锁 mysql_有关mysql的for update以及 死锁问题
weixin_29215509的博客
01-18 846
一、先说锁的概念锁级别：1.行级锁： InnoDB引擎(也支持表级锁，默认是行级锁)，开销大，加锁慢；会出现死锁。锁定粒度最小，发生锁冲突的概率最低，并发度最高。2.表级锁：MylSAM引擎和Memory引擎，开销小，加锁快；不会出现死锁，锁定粒度最大，发生锁冲突的概率最高，并发度最低。3.页级锁：BDB引擎(也支持表级锁)，开销和加锁时间介于行锁和表锁之间；会出现死锁；粒度也介于行锁和表锁之间，...
MySQL的`FOR UPDATE`详解
热门推荐
weixin_44976692的博客
01-25 2万+
通过本博客，我们详细了解了MySQL中的FOR UPDATE语句，它在事务中起到了锁定数据行的关键作用，确保了数据的一致性和可靠性。FOR UPDATE有所帮助。如果有任何问题或建议，请随时与我们分享。下一篇博客将继续介绍更多有关数据库的知识，敬请期待！
Mysql 数据库死锁过程分析(select for update)
09-10
MySQL数据库中的死锁是数据库管理系统中常见的问题，特别是在并发环境下，多事务操作可能导致死锁的发生。本文主要讨论了在使用`SELECT ... FOR UPDATE`语句时遇到的死锁情况，并通过具体的例子深入分析了死锁的原因...
mysql SELECT FOR UPDATE语句使用示例
09-10
MySQL中的`SELECT FOR UPDATE`语句是在事务处理中用于实现数据锁定的一种机制，它主要用于解决多用户并发操作时的数据一致性问题。在InnoDB存储引擎下，MySQL默认的事务隔离级别是`REPEATABLE READ`，这允许事务在...
mysql事务select for update及数据的一致性处理讲解
09-09
FOR UPDATE`在更新同一行时更安全，因为它可以防止死锁，而`SELECT ... LOCK IN SHARE MODE`在读取时会允许其他事务进行读操作，但在尝试更新时可能会引起死锁。 举例来说，假设我们有一个产品表`products`，其中...
mysql varchar能不能超过255个字节及产生的问题。
songkai558919的博客
08-23 1万+
项目里突然varchar字段设置255也不够用了，记得规定不能超过255，今天查了一下，现总结如下： MySQL要求一个行定义长度不能超过 65535 bytes（所有字符串类型字段包括其字段名称占用空间都计算在内， text、blob等大字段类型除外)。所有如果一个表有很多varchar字段的时候，不应该把varchar设置的特别大，会影响后面的字段 InnoDB存储引擎的表索引的前缀长度最长是767字节(bytes)(前缀长度适用于mysql5.6及以前，后续版本有变化) 你如果需要建索引，就
‘The client noticed that the server is not a supported distribution of Elasticsearch‘ 报错及解决办法
songkai558919的博客
08-11 6429
django项目运行的好好的，突然接口查询错误。 观察报错信息 { "code": 400102, "message": "请求错误", "data": { "detail": "The client noticed that the server is not a supported distribution of Elasticsearch" } } 搜索百度无果，随搜索谷歌 查询到新闻链接 链接如下： https://www.there
多用户并发操作的解决方案,同步锁的具体实施方法
songkai558919的博客
02-03 6113
一：并发操作出现的原因 原因：多个动作在一瞬间同时操作同一数据 现象： 多人在某一瞬间通过相同的方式操作同一条数据 多人在某一瞬间通过不同的方式操作同一条数据 在某一瞬间，同一动作，多次执行 二：并发举例及解决办法 针对上述的三种的情况，分别以实际情况进行举例。 【多人在某一瞬间通过相同的方式操作同一条数据】 1.某仓库系统有一品牌商品A，商品A在数据库中只允许存在一条记录，库存的数量是这条数据的一个字段，现有库存100件，在某一天到货了1000件。由于数量比较大，现在需要10名操作员去
MacOS 使用SwitchHosts修改 hosts 不生效的原因及解决方法
songkai558919的博客
10-12 5742
mac下默认不是root用户的文件修改，可能不会立刻起效。
解决bitmap做每日统计，offset偏移量过大，导致内存占用过大的问题思路
songkai558919的博客
03-10 4643
需求：使用redis的bitmap做每日统计 解决思路：使用每天的第一个id作为被减量，这样每天的offset(偏移量)就从1开始，大幅有效的缩减了内存的占用量！ //bitmap的偏移量offset生产,offset越大，占用内存越多，所以以每日第一个id作为minid，作为被减数 //使用guava cache缓存机制获取最小id,设置过期时间为每一天，每天清空一次 private Lo...
mysql事务实现数据更新_mysql事务和锁 SELECT FOR UPDATE
06-10
好的，你的问题是关于 MySQL 事务和锁的实现，特别是 SELECT FOR UPDATE 的使用。MySQL 事务是一组相关的 SQL 查询，它们必须被视为一个单一的、原子的操作，也就是说，这些操作要么全部成功，要么全部失败，不会...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值