LOCK TABLES tbl_name [[AS] alias] lock_type [, tbl_name [[AS] alias] lock_type] ... lock_type: { READ [LOCAL] | [LOW_PRIORITY] WRITE } UNLOCK TABLES
MySQL使客户端会话能够显式地获取表锁，以便与其他会话协作访问表，或者防止其他会话在会话需要互斥访问期间修改表。会话只能为其自身获取或释放锁。一个会话无法获取另一会话的锁，也不能释放另一会话持有的锁。
在更新表时，锁可用于模拟事务或提高速度。
如果使用显式锁定表LOCK TABLES，则触发器中使用的任何表也会隐式锁定.
UNLOCK TABLES显式释放当前会话持有的所有表锁。 在获取新锁之前，隐式释放当前会话持有的所有表锁。
UNLOCK TABLES的另一种用法是释放通过该FLUSH TABLES WITH READ LOCK 语句获取的全局读取锁定，这使您可以锁定所有数据库中的所有表。
表锁只能防止其他会话进行不适当的读取或写入。持有WRITE 锁的会话可以执行表级操作，例如 DROP TABLE或 TRUNCATE TABLE。对于持有会话READ锁，DROP TABLE和TRUNCATE TABLE 操作是不允许的。
以下讨论仅适用于非TEMPORARY表。LOCK TABLES允许（但忽略） TEMPORARY表。
在当前会话中获取表锁，使用 LOCK TABLES 语句
READ [LOCAL] 锁：
持有锁的会话可以读取表（但不能写入表）。
多个会话可以同时获取该表的READ锁。
其他会话可以在不显式获取READ锁的情况下读取表。
使用LOCAL可以在并发插入时不产生冲突。
但是，如果您要在持有READ LOCAL锁的同时使用服务器外部的进程来操作数据库， 则不能使用它。对于 InnoDB表，READ LOCAL与READ相同。
[LOW_PRIORITY] WRITE 锁：
持有锁的会话可以读写表。
只有持有锁的会话才能访问该表。在释放锁之前，没有其他会话可以访问它。
保持WRITE锁定状态时，其他会话对表的锁定请求将阻塞。
该LOW_PRIORITY修饰符无效。在以前的MySQL版本中，它影响了锁定行为，但现在不再如此。现在已弃用，使用它会产生警告。使用WRITE不带 LOW_PRIORITY。
需要锁的会话必须在单个锁表语句中获取所需的所有锁。当这样获得的锁被持有时，会话只能访问锁定的表。例如，在以下语句序列中，尝试访问t2时出错，因为t2在LOCK TABLES语句中未被锁定：
mysql> LOCK TABLES t1 READ; mysql> SELECT COUNT(*) FROM t1; +----------+ | COUNT(*) | +----------+ | 3 | +----------+ mysql> SELECT COUNT(*) FROM t2; ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES
不能在同一个查询中使用相同的名称多次引用锁定的表。请改用别名，并为表和每个别名获取单独的锁：
mysql> LOCK TABLE t WRITE, t AS t1 READ; mysql> INSERT INTO t SELECT * FROM t; ERROR 1100: Table 't' was not locked with LOCK TABLES mysql> INSERT INTO t SELECT * FROM t AS t1;
如果您的语句通过别名引用表，则必须使用相同的别名锁定表。如果不指定别名，则无法锁定表：
mysql> LOCK TABLE t READ; mysql> SELECT * FROM t AS myalias; ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
相反，如果使用别名锁定表，则必须在该语句中使用该别名引用该表：
mysql> LOCK TABLE t AS myalias READ; mysql> SELECT * FROM t; ERROR 1100: Table 't' was not locked with LOCK TABLES mysql> SELECT * FROM t AS myalias;
表锁定和事务的交互
LOCK TABLES和 UNLOCK TABLES与事务进行交互，如下所示：
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 and UNLOCK TABLES关于表锁定和隐式提交一样的约束，例如， START TRANSACTION不会释放全局读锁。
其他隐式导致事务提交的语句不会释放现有的表锁。
在事务表中正确的使用lock tables 和 unlock tables ,比如innodb 表，一个事务开始用SET autocommit=0(而不是start transaction) 后面跟着 lock tables,最后直到显示的提交commit后，才可以使用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释放它内部的表锁，但是对于MYSQL，必须使用UNLOCK TABLES才会释放它的锁。不能设置autocommit=1,因为这样在lock tables 后，innodb会立即释放它的内部表锁，容易发生死锁。如果autocommit=1，innodb不会一直要求内部表锁，是为了帮助老的应用避免非必要的死锁。
ROLLBACK不会释放表锁。