MySQL的start transcation会加锁吗

Posted 2021-04-23 kevinSays

目标

1. 确认mysql transaction开启时是否会加锁

2. Select..for Update的锁与释放机制

MySQL transcation与锁的关系

In the InnoDB transaction model, the goal is to combine the best properties of a multi-versioning database with traditional two-phase locking. InnoDB performs locking at the row level and runs queries as nonlocking consistent reads by default, in the style of Oracle. The lock information in InnoDB is stored space-efficiently so that lock escalation is not needed. Typically, several users are permitted to lock every row in InnoDB tables, or any random subset of the rows, without causing InnoDB memory exhaustion.

Innodb的事务模型目标是将数据库多版本和两阶段锁的最好特点结合起来。InnoDB在执行事务时，像oracle一样，默认采用行级锁和可重复读。在InnoDB中，锁信息是很小的，所以对于存储方面没有很大的需求，就算在比较极端的情况下，多个用户锁定了InnoDB的每一行，或者随机多行的锁定，也不会引起内存溢出。

InnoDB offers all four transaction isolation levels described by the SQL:1992 standard: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE. The default isolation level for InnoDB is REPEATABLE READ.

InnoDB提供SQL-1992标准的四个事务隔离级别: READ UNCOMMITED, READ COMMITED, REPEATABLE READ, SERIALIZABLE. InnoDB默认级别是REPEATABLE READ。

InnoDB supports each of the transaction isolation levels described here using different locking strategies. InnoDB为不同的隔离级别，提供了不同的锁策略。

Repeatable Read. This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other

可重复读这是InnoDB默认的隔离级别，通过快照的方式实现了可重复读。这意味着如果使用的是非锁读请求在一个事务里，读取到的数据总是一致的。

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range.

对于像 SELECT..FOR UPDATE或者 LOCK IN SHARE MODE等这种锁读请求的方式、UPDATE和DELETE请求来说，锁决定于是否语句可以使用一个唯一索引，并且有一个唯一的搜索条件或者范围搜索条件。

• 对于唯一索引并且使用了唯一搜索条件, InnoDB会锁定找到的行，不会加gap lock.

• 对于其他搜索条件时， InnoDB会使用gap lock或者next-key lock(阻塞其他会话插入).

Beginning a transaction (for example, with START TRANSACTION) implicitly commits any current transaction and releases existing table locks 开始一个事务时，会默认提交当前的事务，并且释放表锁。

从上述文档来看，InnoDB开启事务时并不会有表锁，根据要更新的语句会有行级锁。但事务和表锁之间有互相关联的关系，比如在开启事务时会默认提交当前会话中已经存在的事务，并且释放表锁。

验证:

情况一: A开启事务并查询，B进行drop

 
   
   
 

  
    
    
  
Session A:
  
    
    
  
create table test (id bigint(11));
  
    
    
  
insert into test (id) values (1);
  
    
    
  


  
    
    
  
start transaction;
  
    
    
  


  
    
    
  


  
    
    
  
Session B: 
  
    
    
  
insert into test(id) values(2);
  
    
    
  


  
    
    
  


  
    
    
  
Session A:
  
    
    
  
select * from test;
  
    
    
  


  
    
    
  
Session B:
  
    
    
  
drop table test;
 
   
   
 

执行结果: A的select看不到事务开启后的id=2数据，B的drop因为select的原因被阻塞。

情况二: A开启事务，B进行drop, A进行查询

 
   
   
 

  
    
    
  
Session A:
  
    
    
  
start transaction;
  
    
    
  


  
    
    
  
Session B:
  
    
    
  
drop table test;
  
    
    
  


  
    
    
  
Session A:
  
    
    
  
select * from test;
 
   
   
 

B的drop不会阻塞，A的查询会返回表不存在的错误。

从上述验证结果可以得到以下结果:

1. 开启事务并不会对表进行加锁

2. 事务中的语句会对表或者记录进行加锁

3. 一个表可以并发执行多个事务

相关资料

1. InnoDB Transaction Model

2. Interaction of Table Locking and Transactions

Select..for Update的锁与释放机制

A SELECT ... FOR UPDATE reads the latest available data, setting exclusive locks on each row it reads. Thus, it sets the same locks a searched SQL UPDATE would set on the rows.

对于SELECT ... FRO UPDATE会读取最新的数据，并且设置排他锁在需要的每一行记录上，就像Update一样。

If you query data and then insert or update related data within the same transaction, the regular SELECT statement does not give enough protection. Other transactions can update or delete the same rows you just queried

如果在一个事务里查询并且对数据进行操作，普通的select语句并不能提供有效的保护。其他事务可以在这个过程中对这些行更新或者删除。

SELECT ... FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.

SELECT ... FOR UPDATE会在每一个要锁定的记录设置一个排他next-key排他锁。这个是需要一个唯一索引来搜索满足条件的唯一行，找到之后在索引记录上加锁。

To avoid deadlocks when performing multiple concurrent write operations on a single InnoDB table, acquire necessary locks at the start of the transaction by issuing a SELECT ... FOR UPDATE statement for each group of rows expected to be modified, even if the data change statements come later in the transaction. If transactions modify or lock more than one table, issue the applicable statements in the same order within each transaction.

为了避免多个并非写InnoDB产生思索，可以在事务开始时用 SELECT...FOR UPDATE的方式锁定要修改的每一行。如果事务修改或者锁定涉及多个表，建议采用同样的顺序来进行锁定。