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.
