mysql的并发处理机制_下篇 mysql的并发处理机制_上篇
MySQL的并发处理机制，有MVCC及锁机制来处理，上篇简要说明了 MVCC及隔离级别：mysql的并发处理机制_上篇 ，这篇来讲说mysql下的锁。
html
舒适提示：下文有几个表格长度较长，右下角的博文导航目录会挡道，浏览时，能够点击 导航目录的左下角按钮收缩目录：
1 Innodb的锁
在innodb中，有4种类型的锁：IX、X、IS及S锁，其说明以下：
| 类型 | 说明 | 场景 |
| S | 共享锁 | 针对于RS隔离级别的查询或者添加Lock in share mode的SELECT查询而产生的锁 |
| X | 排它锁 | 针对于update、delete、insert操做而产生的锁 |
| IS | 意向共享锁 | 表级别的锁，在添加S锁以前对表格添加IS锁 |
| IX | 意向排他锁 | 表级别的锁，在添加X锁以前对表格添加IX锁 |
1.1 锁定兼容状况
四个锁之间的兼容性，须要分红两种状况来讨论，锁粒度小于表级别的锁的兼容状况，表级的锁兼容状况。
- 锁粒度小于表级别的锁的兼容状况
- 对于这两行锁的兼容说明以下：
- 假设有一行数据，添加了行锁S锁，那么这个行数据，能够提供给其余事务进行S锁的申请和添加，可是不支持其余事务对这一行进行X锁的申请和添加。好比，事务A，对 pk100 这一行进行了 查询操做并添加了S锁，那么其余事务仍然能够对这一行数据进行查询，可是不能对这行数据进行 UPDATE 跟 DELETE 操做，会处于锁等待状况，直到该事务A结束并释放S锁；
- 假设有一行数据，添加了X锁，那么这个行数据，不容许其余事务对这一行数据进行加锁。好比，事务A，对pk100这一行进行了UPDATE操做，那么其余事务在事务A没有结束以前，都没法对这一行数据申请 S锁。
- 表级的锁兼容状况
- 对于表级别的锁兼容性以下：
- 当一个表格持有S表锁时，不须要其余事务对该表格申请X锁跟IX锁，可是容许申请S跟IS锁。好比，事务A对表格tba全表读，加了S表锁，期间支持其余事务对tba全表读（申请S表锁成功）、支持其余事务对tba行数据查询（申请IS表锁成功），可是不支持对表格全表的修改操做（申请X表锁等待）跟不支持对表格行数据修改操做（申请IX表锁等待）；
- 当一个表格持有X表锁时，持有锁期间，不支持其余全部锁的申请；
- 当一个表格持有IS表锁时，容许申请 S表锁、IS表锁、IX表锁，可是不支持X表锁申请。
- 好比，事务A对表格tba 查询了 id = 10（id为主键）这一行数据，这个时候，表格tba持有IS表锁，id = 10 这一行持有 S 行锁，期间，支持其余事务对 tba 全表查询（申请表锁S成功）或者 基于索引查找（申请表锁IS成功）
- 若是须要对行 id = 20 进行数据修改，则会先申请 tba 的表锁 IX（申请成功），而后再申请id=20行锁X （申请成功）；若是须要对 id = 10 这一行数据进行修改，则会申请 tba的表锁 IX（表锁申请成功），而后申请 id = 10 的行锁X（申请堵塞，由于 id = 10 正持有S锁）；
- 若是须要对表格进行全表修改，须要申请表锁（X锁），这个时候，IS锁的优点来了，当查看表格是否有其余事务在访问操做时，一看表锁IS就知道有其余事务对表格内部某些数据持有S锁，而且尚未释放，那么这个时候，申请X锁就会处于等待状态，而不须要一行一行去查询每一行数据有没有被其余事务持有锁，能够大规模的减小查询 锁申请状况；
- 当一个表格持有IX表锁时，支持申请IS、IX表锁，可是不兼容S、X表锁。
- 好比，事务A对表格 tba 中 id=10 （id为主键）进行进行 数据修改，这个时候，会对表格 tba 先申请一个 IX 表锁（申请成功），而后申请 id =10 的 X 行锁，申请成功，则 事务A 持有 IX 表锁、id=10的X 行锁，此时事务B 查询 id=20的行，申请表锁 IS 成功，申请 id=20的 S 行锁成功；事务C 修改 id=30的行数据，申请表锁 IX 成功，申请 id=30的行锁 X成功；可是，事务D中，对整个表格发起update或者全表SELECT操做，须要申请 X表锁或者S表锁，正常状况下，应该要对表格的每一行数据进行查看，确保每一行数据的行锁状况，可是由于有了意向锁，事务D一看到 tba 持有 了IX锁，则明白，tba 中某些行持有X锁，则会不兼容其余事务对tba 表锁S ，表锁X的申请。
- 为何要引入意向表锁？
- 在没有意向锁的时候，若是事务T 须要给表格 A 添加 一个S 表锁，那么就意味这这个表格内部的每一行数据，都不能有X锁，才可以申请 S 表锁成功，若是表格数据不少，一行行查找很是浪费加锁时间，这个时候，就出现了表格意向锁，当表格内部某些行发生 UPATE DELETE INSERT操做，则会对表格 加上 一个意向 IX 表锁，这样 事务T在申请 表格A的 S 表锁时，只须要检查 表格 A 是否有 IX表锁，若是有，则意味内部有 部分行数据持有X锁，则直接进入等待状况，若是表格没有 IX表锁，则直接申请S表锁成功，这是一个多么节约加锁时间的操做！
1.2 锁的级别
- Table Lock
- 表锁，若是没有where条件、无可用索引或者获取的行记录过多，则会使用 table full scan，添加表锁
- Record Lock
- 记录锁，若是执行计划使用了索引，则会根据索引的查找状况添加行锁
- Gap Lock
- 在RR、RS隔离级别，发生在索引值之间，在连续的两个索引值之间添加锁，加锁后，这两个索引值之间，没法插入新的索引值，不包含行记录
- Next-Key Lock
- Record Lock 跟Gap Lock的组合，合体成为Next-KEY Lock
表锁、行锁都相对好理解，这里尝试简单说明下 GAP LOCK。
假设当前隔离级别为RR，表格 tbgap( id int auto_increment primary key not null , name varchar(50) , sort int , key ix_sort (sort)) engine=innodb;
表格数据以下：
在索引ix_sort上，一共有7个间隙，分别为（-∞，(1,6)），（(1,6)，(2,5)），（(2,5)，(3,2)），（(3,2)，(5,4)），（(5,4)，(6,1)），（(6,1)，(7,3)），（(7,3)，+∞），而根据实际的隔离级别及锁申请状况，加在这些间隙上的锁，则成为 GAP LOCK 。
1.3 锁与隔离级别（不考虑 lock in shar mode跟for update ）
- RU，读未提交记录，不加锁读，正常写锁；
- RC，快照读，无锁；当前读，加 Record Lock
- RR，快照读，无锁；当前读，对读取到的记录加 Record Lock，同时为了确保where条件范围内的数据无变化，会增长Next key lock
- RS，读写均为当前读，不支持快照读。包括select 在内，对读取到的记录加 Record Lock，同时为了确保where条件范围内的数据无变化，会增长Next key lock。
2 锁的申请与释放过程
看SQL语句的锁状况，须要结合隔离级别、执行计划、表结构等，同一个SQL，不一样的隔离级别、表结构、执行计划，其锁状况不必定是同样的！
本次模拟这3个表格，age列分别：无索引、有通常索引、有惟一索引。表结构结束及数据以下：
CREATE TABLE tb_no_index ( id int primary key not null auto_increment, age int not null, name varchar(100) );
CREATE TABLE tb_index ( id int primary key not null auto_increment, age int not null, name varchar(100) KEY ix_age(age) );
CREATE TABLE tb_unique_index ( id int primary key not null auto_increment, age int not null,name varchar(100) UNIQUE KEY ix_age(age) );
INSERT INTO tb_no_index(age) values(2),(9),(21),(4),(7),(25);
INSERT INTO tb_index(age) values(2),(9),(21),(4),(7),(25);
INSERT INTO tb_unique_index(age) values(2),(9),(21),(4),(7),(25);
每一个表格IX_age的索引行数就据以下图展现：
|
age
|
2
|
4
|
7
|
9
|
21
|
25
|
|
id
|
1
|
4
|
5
|
2
|
3
|
6
|
每一个表格主键上面的行数就据以下图展现：
|
id
|
1
|
2
|
3
|
4
|
5
|
6
|
|
age
|
2
|
9
|
21
|
4
|
7
|
25
|
|
name
|
null
|
null
|
null
|
null
|
null
|
null
|
2.1 Read Uncommitted
全部事务隔离级别设置： set session transaction isolation level read Uncommitted ;
RU是读未提交，不添加 LOCK IN SHARE MODE 跟 FOR UPDATE 的 SELECT 语句，均为读未提交，不加锁，存在脏读、不可重复读及幻读。
全部UPDATE、DELETE、INSERT获取当前读记录，加锁。
|
表格 SQL
|
select * from tbname
where age/id ...
|
update tbname set name=...
where id = 4
|
update tbname set name=...
where age = 21
|
update tbname set name=...
where age between 5 and 15
|
|
tb_no_index
|
读不加锁，读未提交数据
可能有脏读、不可重复读及幻读
|
当前读，根据主键修改数据
tbname 加意向表锁 IX
id=4 加 行锁 X
|
表格的age列无索引，因此update过程当中，全表加X锁
支持semi-constent-read，若是有其余update语句修改其余行不堵塞，可是不支持 select ... for update
|
同左
|
|
tb_index
|
表格的age列有索引，update过程当中
tb_index 加 表格意向锁 IX
age索引上面，age=21 行添加行锁 X
再在主键上，给id=3 这一行数据，添加行数 X
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
|
||
|
tb_unique_index
|
同上
|
同上
|
2.2 Read Committed
全部事务隔离级别设置： set session transaction isolation level read committed ;
RC是读已提交，不添加 LOCK IN SHARE MODE 跟 FOR UPDATE 的 SELECT 语句，均为 快照读，不加锁，同个事务内读取同一个版本的数据，可能非最新数据，可是不存在脏读、不可重复读及幻读状况。
全部UPDATE、DELETE、INSERT获取当前读记录，加锁。
下表中，黄绿色 字体 是RC与RU隔离级别不一样的地方，仔细阅读分析结果能够知道，在 RU 跟 RC 间，最大的区别在于 SELECT 的查询模式，RU 为 读未提交，而 RC 为快照读。UPATE/DELETE/INSERT的加锁模式类同。
|
表格
SQL
|
select * from tbname
where age/id ...
|
update tbname set name=...
where id = 4
|
update tbname set name=...
where age = 21
|
update tbname set name=...
where age between 5 and 15
|
|
tb_no_index
|
快照读，不加锁
读取的数据不必定是最新版本，可是事务内的全部查询读取数据都是同一版本的行数据，不存在脏读、不可重复读及幻读的状况
|
当前读，根据主键修改数据
tbname 加意向表锁 IX
id=4 加 行锁 X
|
表格的age列无索引，因此update过程当中，全表加X锁
支持semi-constent-read，若是有其余update语句修改其余行不堵塞，可是不支持 select ... for update
|
同左
|
|
tb_index
|
表格的age列有索引，update过程当中
tb_index 加 表格意向锁 IX
age索引上面，age=21 行添加行锁 X
再在主键上，给id=3 这一行数据，添加行数 X
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
|
||
|
tb_unique_index
|
同上
|
同上
|
2.3 Read Repeatable
全部事务隔离级别设置： set session transaction isolation level repeatable read ;
RR隔离级别中，SELECT操做支持快照读，全部的UPDATE/DELETE/INSERT加锁，锁类型会新增一个GAP LOCK。
|
表格 SQL
|
select * from tbname
where age/id ...
|
update tbname set name=...
where id = 4
|
update tbname set name=...
where age = 21
|
update tbname set name=...
where age between 5 and 15
|
|
tb_no_index
|
快照读，不加锁
读取的数据不必定是最新版本，可是事务内的全部查询读取数据都是同一版本的行数据，不存在脏读、不可重复读及幻读的状况
|
当前读，根据主键修改数据
tbname 加意向表锁 IX
id=4 加 行锁 X
|
表格的age列无索引，因此update过程当中
全表加X锁，期间全表堵塞UPDATE\DELETE\INSERT
|
同左
|
|
tb_index
|
表格的age列有索引，update过程当中
tb_index 加 表格意向锁 IX
age索引上面，age=21 行添加行锁 X
再在主键上，给id=3 这一行数据，添加行数 X
你觉得结束了！并无，这里有趣了！
还会添加两个gap lock （(9,2) ,（21,3)），（(21,3), (21,25)）
这里咱们单独拎出小表格来分析。
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
同时会在索引 age的值上添加 3个 gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）、（(9,2)，(21,3)）
|
||
|
tb_unique_index
|
觉得跟上面的加锁范围同样，no no no
惟一索引列上 每个age都是惟一的，也就是age=21只有一个，不会再INSERT一个新的 age =21进来，故在这里不须要加gap lock，加锁状况以下：
tb_index 加 表格意向锁 IX
age=21 行添加行锁 X
age索引上面，age=21 行添加行锁 X
再在主键上，给id=3 这一行数据，添加行数 X
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
同时会在索引 age的值上添加 3个 gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）、（(9,2)，(21,3)）
可是，范围查询添加到gap lock在其余状况下跟非惟一索引会有一些差异，能够看下表的例子。
|
这里作亮点补充说明：
2.3.1 RR下的非惟一索引加锁状况
update tbname set name=... where age = 21
还记得上篇文章说过 RR隔离级别能够防止 幻读吗？由于在RR隔离级别中，加多了next-key = record lock + gap lock，gap lock是加在索引值之间的锁。也就是 当修改 age=21 的行数据时,除了 在 age=21 这一行添加 X record lock ， 还在 （(9,2) ,（21,3)），（(21,3), (21,25)）这两个age值得范围内添加 gap lock。加锁的状况是：tb_index添加 IX意向锁，age索引上添加age=21的 x record lock，再在主键上的行记录 id=5 添加 X record lock，同时在 age 值上添加两个 gap lock，分别为（(9,2) ,（21,3)），（(21,3), (21,25)）。
注意这里有个误区，不少小伙伴会认为，那么这么加gap锁，则意味着，当update age=21这一列时， 9<age<25 ，这个范围内，是不容许进行 UPATE/DELETE/INSERT的。这种推测其实是不完整的，由于它没考虑到跟主键！！！
注意，每次写gap lock的时候，都是有加上主键值的。好比这里，当更新 age=21这列时，加了 （(9,2) ,（21,3)），（(21,3), (21,25)） 这两个范围的 GAP LOCK，那么在当前update age=21的事务尚未结束的状况下，假设有两条修改SQL的语句：
update tbname set age=9 where id = 1;
update tbname set age=9 where age = 4;
这两条SQL，是可以正常执行，仍是堵塞呢？
innodb中，索引按照二叉树排列顺序，而这两条SQL修改后在IX_AGE上的索引值分别为：（9，1）、（9，4），能够发现（9，1）在键值（9，2）的左边，不在GAP LOCK的范围内，因此，能够正常执行；而（9，4）在键值的右边，恰好在GAP LOCK的范围内，会被堵塞！总结：第一条UPDATE SQL，正常秩序；第二条UPDATE SQL会被堵塞。
因此，考虑GAP LOCK的时候，必定要注意结合整个索引键值来分析，而索引键值=索引值+主键。
2.3.2 RR下的惟一索引加锁状况
update tbname set name=... where age between .. and ...
由于惟一索引上面的索引键值都是惟一的，故不会出现重复值的插入的状况，下表罗列了一样的 范围查询修改语句，在惟一索引及非惟一索引上加 GAP_LOCK的状况。
表格数据以下：
加GAP_LOCK的状况以下（注意注意，方便查看，省略了主键值，其实是须要添加上主键键值的）：
|
update tbname set name=...
where age between 1 and 7
|
update tbname set name=...
where age between 2 and 7
|
update tbname set name=...
where age between 5 and 10
|
update tbname set name=...
where age between 15 and 50
|
|
|
tb_index
|
(-∞,2),(2,4),(4,7),(7,9)
|
(-∞,2),(2,4),(4,7),(7,9)
|
(4,7),(7,9),(9,21)
|
(9,21),(21,25),(25,+∞)
|
|
tb_unique_index
|
(-∞,2),(2,4),(4,7)
|
(2,4),(4,7)
|
(4,7),(7,9),(9,21)
|
(9,21),(21,25),(25,+∞)
|
2.4 Read Serializable
全部事务隔离级别设置： set session transaction isolation level
Serializable ;
|
表格 SQL
|
select * from tbname
where age/id ...
|
update tbname set name=...
where id = 4
|
update tbname set name=...
where age = 21
|
update tbname set name=...
where age between 5 and 15
|
|
tb_no_index
|
不支持快照读，全部SELECT都是当前读，全部SELECT操做都须要加S锁,除主键定值查找\惟一索引定值查找外,其余基于索引或者主键的范围查找都会添加 S GAP LOCK。并发度是四个隔离级别中性能最差的。
|
当前读，根据主键修改数据
tbname 加意向表锁 IX
id=4 加 行锁 X
|
表格的age列无索引，因此update过程当中
全表加X锁，期间全表堵塞UPDATE\DELETE\INSERT
|
同左
|
|
tb_index
|
表格的age列有索引，update过程当中
tb_index 加 表格意向锁 IX
age索引上面，age=21 行添加行锁 X
再在主键上，给id=3 这一行数据，添加行数 X
在age索引上 添加两个gap lock （(9,2) ,（21,3)），（(21,3), (21,25)）
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
同时会在索引 age的值上添加 3个 gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）、（(9,2)，(21,3)）
|
||
|
tb_unique_index
|
惟一索引列上 每个age都是惟一的，也就是age=21只有一个，不会再INSERT一个新的 age =21进来，故在这里不须要加gap lock，加锁状况以下：
tb_index 加 表格意向锁 IX
age=21 行添加行锁 X
|
表格的age列有索引，update过程涉及age=7,9 两行数据
tb_index 加表格意向锁 IX
age索引上面，age=7，age=9 行添加行锁 X
再在主键上，给id=2，id=5 这一行数据，添加行数 X
同时会在索引 age的值上添加 3个 gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）、（(9,2)，(21,3)）
可是，范围查询添加到gap lock在其余状况下跟非惟一索引会有一些差异，能够看下表的例子。
|
这里详细的来分析下 RS 隔离级别下的SELECT操做加的锁：
|
表格 SQL
|
select * from tbname
where id=5
|
select * from tbname
where id betwee 5 and 15
|
select * from tbname
where age=21
|
select * from tbname
where age betwee 5 and 9
|
|
tb_no_index
|
主键定值查找
表格tbname 添加 IS 意向锁
id=5 添加 S锁
|
主键范围查找
表格tbname 添加 IS 意向锁
id=5,id=6 两行数据 添加 S锁
同时添加2个 S GAP LOCK ,分别为 （(5,7),(6,25)）跟（(6,25),+∞）
|
全表查找
表格 tbname 添加 IS 意向锁
因为全表查找，整个表格 再次添加 S 表锁
|
全表查找
表格 tbname 添加 IS 意向锁
因为全表查找，整个表格 再次添加S 表锁
|
|
tb_index
|
ix_age索引查找
表格tbname 添加 IS 意向锁
索引上 age = 21 添加 S 行锁
主键上 id=3 添加 S 行锁
同时添加 2个
S GAP LOCK ，分别为 （(9,2) ,（21,3)），（(21,3), (21,25)）
|
ix_age索引查找
表格tbname 添加 IS 意向锁
age索引上面，age=7，age=9 行添加行锁 S
再在主键上，给id=2，id=5 这一行数据，添加行数 S
同时会在索引 age的值上添加 3个 S gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）、（(9,2)，(21,3)）
|
||
|
tb_unique_index
|
ix_age索引查找
表格tbname 添加 IS 意向锁
索引上 age = 21 添加 S 行锁
主键上 id=3 添加 S 行锁
因为age列惟一，故不须要添加GAP LOCK
|
ix_age索引查找
表格tbname 添加 IS 意向锁
age索引上面，age=7，age=9 行添加行锁 S
再在主键上，给id=2，id=5 这一行数据，添加行数 S
同时会在索引 age的值上添加
2 个 S gap lock，分别为
（(4,4)，(7,5)）、（(7,5)，(9,2)）
|
至此，已说明了四个隔离级别是如何加锁，那么，释放锁呢？
在MySQL INNODB中，遵循的是 strong strict 2-PL，也就是全部的write lock 跟read lock 都是在 事务 commit后才释放。
3 SQL分析
考虑到下文的例子，这里补充两个概念。
ICP：
MRR：
假设表格 tb_lock ( id int primary key not null, age int,score int,name varchar(10), key ix_age_score ( age, score ) ) 数据修改以下 ：
假设MySQL当前的隔离级别为 RR，执行 UPDATE tb_index WHERE age between 5 and 22 and score between 1 and 10 and name is not null，其执行计划以下：
那么，是如何加锁的呢？
首先，能够看到是根据索引 ix_age_score 查找，那么分为两种状况来分析，第一种，数据库支持ICP；第二种，数据不支持ICP。
3.1 支持ICP状况
当数据库支持ICP的时候，根据复合索引第一列 age 查找 age between 5 and 22，而后在索引内部过滤 score between 1 and 10后，取得索引值后，若是数据库支持 MRR，则会把取得的索引值放到buffer中，对主键进行排序，而后能够根据顺序的主键值去 主键中查找行数据，若是不支持，则跳过这一步排序步骤，直接根据索引值内部的主键值，查找主键行数，最后过滤 name is not null 。
加锁过程以下，tb_lock添加 IX 意向锁，在索引 ix_age_score 给索引值（7，10，5），（21，4，3）添加上 X record lock，并添加4个 X GAP LOCK，如图片红色素箭头展现，分别为（(4,7,4), (7,10,5)）,（(7,10,5), (9,15,2)）,（(9,15,2),(21,4,3)）,（(21,4,3)，(25,1,6)）,最后在主键上给id=3及id=5 两行数就添加X record lock。
3.2 不支持ICP状况
当数据库不支持ICP的时候，根据复合索引第一列 age 选择 age between 5 and 22，而后根据筛选的索引值 （7，10，5），（9，15，2），（21，4，3）中的主键 五、二、3，找到对应的行数据，再在行数据中 过滤 score between 1 and 10 and name is not null。
加锁过程以下，tb_lock添加 IX 意向锁，在索引 ix_age_score 给索引值（7，10，5），（9，15，2），（21，4，3）添加上 X record lock，并添加4个 X GAP LOCK，如图片红色素箭头展现，分别为（(4,7,4), (7,10,5)）,（(7,10,5), (9,15,2)）,（(9,15,2),(21,4,3)）,（(21,4,3)，(25,1,6)）,最后在主键上给id=二、id=三、id=5 两行数就添加X record lock。
参考文档：http://hedengcheng.com/?p=771#_Toc374698321
相关文章
- 1. Hibernate——事务处理和并发机制
- 2. 什么是高并发 ，高并发处理机制
- 3. nodejs处理高并发的原理机制
- 4. x265中的并行处理机制
- 5. MySQL的高并发处理技术MVCC
- 6. Mysql锁机制与并发控制
- 7. MySQL并发访问控制机制
- 8. Mysql的锁机制与PHP文件锁处理高并发简单思路
- 9. Mysql的并发控制原理
- 10. php实现并发处理之curl篇
- 更多相关文章...
- • TiDB数据库的管理机制 - NoSQL教程
- • PHP MySQL 预处理语句 - PHP教程
- • 漫谈MySQL的锁机制
- • Docker容器实战(六) - 容器的隔离与限制
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
相关文章
- 1. Hibernate——事务处理和并发机制
- 2. 什么是高并发 ，高并发处理机制
- 3. nodejs处理高并发的原理机制
- 4. x265中的并行处理机制
- 5. MySQL的高并发处理技术MVCC
- 6. Mysql锁机制与并发控制
- 7. MySQL并发访问控制机制
- 8. Mysql的锁机制与PHP文件锁处理高并发简单思路
- 9. Mysql的并发控制原理
- 10. php实现并发处理之curl篇