2. show global variables like ‘tx_isolation ';
| tx_isolation | READ-COMMITTED |
看看实测步骤:
session 1 session 2
begin
begin
select * from v where id=1;
| id
| name |
|
1 | name11 |
select * from v where id=1;
| id
| name |
|
1 | name11 |
select * from v where id=1 lock in share
mode;
| id
| name |
|
1 | name11 |
select * from v where id=1 lock in share
mode;
| id
| name |
|
1 | name11 |
session1 和 sesssion2 请求的都是共享锁,不会互斥
无需等待。
select * from v where id=1 for update;
| id
| name |
3. |
1 | name11 |
这个时候,由于 session2 发起了 lock in share mode,需要
请求一个共享锁,和 for update 所需要的排它锁是互斥的,
因此 session1 需要等待 session2 提交或回滚才能继续。
commit;
select * from v where id=1;
| id
| name |
|
1 | name11 |
select * from v where id =1 for update;
或者
select * from v where id =1 lock in share
mode;
update v set name = 'name 2' where id=1; session1 首先发起了一个 select ..for update 请求,
记录加一个排它锁,因此 session2 的请求会被等待
session1 提交或者回滚。
commit;
| id
| name |
|
1 | name 2 |
select * from v where id =1;
| id
| name |
|
1 | name 2 |
select * from v where id =1;
| id
| name |
|
1 | name11 |
select * from v where id =1 lock in share
mode;
| id
| name |
|
1 | name 2 |
可以看到,如果只是发起最简单的 select 请求,则
结果是 session2 发生时看到的快照;如果发起一个
4. for update 或 select..lock in share mode,则可以看到
快照。
这是因为 select…for update 或 select…lock share mo
得最新快照,并且请求加一个排它或者共享 next-k
而普通的 select 查询不会请求加任何锁。
update v set name = ‘name 1’ where id =1;
commit;
select * from v where id=1;
| id
| name |
|
1 | name 1 |
可以看到 session2 提交后的最新结果。
select * from v where id=1;
| id
| name |
|
1 | name 1 |
可以看到 session2 提交后的最新结果。
2、隔离级别为:REPEATABLE
READ
REPEATABLE READ
这是 InnoDB 的默认隔离级别。带唯一搜索条件使用唯一索引的 SELECT ...
FOR UPDATE, SELECT ... LOCK IN
SHARE MODE, UPDATE
和 DELETE 语句只锁定找到的索引记录,而不锁定记录前的间隙。用其它搜索
5. 条件,这些操作采用 next-key 锁定,用 next-key 锁定或者间隙锁定锁住搜索的
索引范围,并且阻止其它用户的新插入。
在持续读中,有一个与之前隔离级别重要的差别:在这个级别,在同一事务内
所有持续读读取由第一次读所确定的同一快照。这个惯例意味着如果你在同一事
务内发出数个无格式 SELECT 语句,这些 SELECT 语句对相互之间也是持续的,
请参阅 15.2.10.4 节,“持续非锁定读”。
show global variables like ‘tx_isolation ';
| tx_isolation | REPEATABLE-READ |
看看实测步骤:
session 1 session 2
begin;
begin;
select * from v where id=1 lock in share
mode;
| id
| name |
|
1 | name 1 |
select * from v where id=1 lock in share
mode;
| id
| name |
|
1 | name 1 |
session1 和 sesssion2 请求的都是共享锁,不
6. 会互斥,因此无需等待。
select * from v where id=1 for update;
| id
| name |
|
1 | name 1 |
这个时候,由于 session2 发起了 lock in share
mode,需要请求一个共享锁,和 for update
所需要的排它锁是互斥的,因此 session1 需
要等待 session2 提交或回滚才能继续。
commit;
begin;
select * from v where id=1;
| id
| name |
|
1 | name 1 |
update v set name='name 2' where id=1;
select * from v where id=1 for update;
或
select * from v where id =1 lock in share
mode;
session1 首先发起了一个 select ..for update
请求 ,会 对该 记录 加一 个排 它锁 ,因 此
session2 的请求会被等待,直到 session1 提
交或者回滚。
commit;
| id
| name |
|
1 | name 2 |
select * from v where id=1;
| id
| name |
|
1 | name 2 |
select * from v where id=1 lock in share
mode;
| id
| name |
|
7. 1 | name 2 |
select * from v where id=1;
| id
| name |
|
1 | name 2 |
这个时候,不管是 select…lock in
share mode 还是 select…for update,还是普
通的 select,得到的结果都是 session 1 更新
后提交的数据。
update v set name = 'name 1' where id=1;
select * from v where id=1;
| id
| name |
|
1 | name 2 |
commit;
select * from v where id=1 ;
| id
| name |
|
1 | name 1 |
select * from v where id=1 ;
| id
| name |
|
1 | name 1 |
关于锁,摘取手册中的几条,更具体的请看 mysql 手册,"存储引擎和表类型" =
> "在 InnoDB 中不同 SQL 语句设置的锁定" 这节。
· SELECT ...
FROM 是一个持续读,读取数据库的快照并且设置不锁定,除非事务隔离级别
被设为 SERIALIZABLE。对于
8. SERIALIZABLE 级别,这个设置对它遇到的索引记录设置共享的 next-key 锁定。
· SELECT ... FROM ... LOCK IN SHARE
MODE 对读遇到的所有索引记录设置共享的 next-key 锁定。
· SELECT ... FROM ... FOR
UPDATE 对读遇到的所有索引记录设置独占的 next-key 锁定。