mysql的LOCK TABLES和UNLOCK TABLES与Transactions（事务）的交互

转载：LOCK TABLES和UNLOCK TABLES与Transactions的交互

LOCK TABLES对事务不安全，并且在试图锁定表之前隐式提交任何活动事务。
UNLOCK TABLES只有在LOCK TABLES已经获取到表锁时，会隐式提交任何活动事务。对于下面的一组语句，UNLOCK TABLES释放了全局读锁，但是因为没有表锁，不会提交事务。
FLUSH TABLES WITH READ LOCK;
START TRANSACTION;
SELECT ... ;
UNLOCK TABLES;
开始一个事务（例如，START TRANSACTION）隐式地提交任何当前事务，会释放现有的表锁。
FLUSH TABLES WITH READ LOCK获取全局的读锁而不是表锁，所以他不会有像LOCK TABLES和UNLOCK TABLES对表锁和隐式提交一样的行为。例如，START TRANSACTION不会释放全局的读锁。
ROLLBACK不会释放表锁。
正确的使用LOCK TABLES和UNLOCK TABLES与Transactions，例如对于InnoDB表，使用事务前设置SET autocommit = 0，LOCK TABLES前不加START TRANSACTION，直到提交事务以后再执行UNLOCK TABLES。例如，你想写入表t1，和读取表t2，可以这样做：
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会在调用commit时释放内部表锁，但是如果MySql想要释放表锁，必须调用UNLOCK TABLES（第二条），且拥有内部表锁。所以必须设置SET autocommit = 0，因为InnoDB默认autocommit = 1，执行LOCK TABLES时，马上就会commit，并释放内部表锁。这样就极易导致死锁发生。

其实，即便是设置了autocommit = 1，LOCK TABLES和事务还是不友好。例如，第二个LOCK TABLES会将前面的事务提交：

SET autocommit=0;
LOCK TABLES foo WRITE;
INSERT INTO foo (foo_name) VALUES ('John');
LOCK TABLES bar WRITE; -- Implicit commit
ROLLBACK; -- No effect: data already committed
在很多情况下，InnoDB下SELECE...FOR UPDATE已经取代了LOCK TABLES，例如：

START TRANSACTION;
SELECT COUNT(*) FROM foo FOR UPDATE; -- Lock issued
INSERT INTO foo (foo_name) VALUES ('John');
SELECT COUNT(*) FROM bar FOR UPDATE; -- Lock issued, no side effects（没有影响）
ROLLBACK; -- Rollback works as expected(预期执行)
LOCK TABLES和UNL语句OCK TABLES是在服务器层实现的，和存储引擎无关。他们有自己的用途，但不能代替事务处理，如果需要用到事务，还是应该选择事务型存储引擎。一般情况下，如果使用的InnoDB存储引擎，没有必要使用LOCK TABLES语句。会严重影响性能，InnoDB的行级锁工作得更好。