14.3.5.1 Interaction of Table Locking and Transactions 表锁和事务的相互作用

14.3.5.1 Interaction of Table Locking and Transactions  表锁和事务的相互作用

LOCK TABLES 和UNLOCK TABLES  交互实用事务如下:

1. LOCK TABLES 不是事务安全的和隐式提交任何活动的事务 在尝试锁定表前

2.UNLOCK TABLES 隐式提交任何活动事务,但是只有如果LOCK TABLES 已经用于获得table locks.

比如, 下面的语句集,UNLOCK TABLES 释放全局锁 但是不会提交事务 因为没有表锁定是生效的。

FLUSH TABLES WITH READ LOCK;
START TRANSACTION;
SELECT ... ;
UNLOCK TABLES;

开始一个事务(例如,START TRANSACTION) 隐式的提交任何当前的事务和释放存在表锁

FLUSH TABLES WITH READ LOCK 需要一个全局的read lock ,不是table locks,

因此它不是服从于相同的行为作为LOCK TABLES 和UNLOCK TABLES 遵守表锁定和隐式提交。

比如, START TRANSACTION 不会释放全局read lock

正确的方式使用LOCK TABLES 和UNLOCK TABLES 在事务表,比如InnoDB 表,

是开始一个事务 设置autocommit = 0(不是START TRANSACTION）跟着lock tables,

不需要调用UNLCOK TABLES 直到你显示的提交事务

SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
... do something with tables t1 and t2 here ...
COMMIT;
UNLOCK TABLES;

当你调用LOCK TABLES时,InnoDB 内部占用它自己的表锁,和MySQL 占用它自己的表锁。

InnoDB 释放它内部表锁 在下次提交时,但是MySQL 释放它的表锁,你需要调用UNLOCK TABLES.

你不能设置autocommit = 1, 因为InnoDB 释放它的内部的table lock 立即在调用LOCK TABLES之后,

deadlocks 可以很轻易的发生。InnoDB 不需要获得内部表锁 如果 autocommit = 1, 

ROLLBACK does not release table locks.