MySQL允许客户端会话显式地获取表锁，以便与其他会话协作访问表，或者防止其他会话在其需要独占表时使用表。这个能力就是通过LOCK TABLES和UNLOCK TABLES实现的。
LOCK TABLES用于显示的获取表锁，UNLOCK TABLES显式释放当前会话持有的任何表锁。
MySQL 5.7版本中它们的完整语法是：
LOCK TABLES
tbl_name [[AS] alias] lock_type
[, tbl_name [[AS] alias] lock_type] …
lock_type: {
READ [LOCAL]
| [LOW_PRIORITY] WRITE
}
UNLOCK TABLES
LOCK TABLES可以为基表或视图获取表锁。必须具有要锁定的每个对象的“LOCK TABLES”权限和“SELECT”权限。
不同的锁类型有不同的效果。
READ [LOCAL]锁:
持有锁的会话可以读取表(但不能写入表)。
多个会话可以同时获取表的read锁。
其它会话可以在不显式获取读锁的情况下读取表。
加上LOCAL关键字，表示在持有锁的同时允许其它会话执行非冲突插入语句(并发插入)。但是，如果要在持有锁的同时使用外部进程操作数据库，则不能使用READ LOCAL。对于InnoDB表，READ LOCAL与READ相同。
会话1登入，并修改提示符包含session1字样，然后对emp表读取，可以进行，然后用lock tables给emp表加read锁定。
root@database-one 13:57: [(none)]> prompt \u@database-one \R:\m:\s [\d] session1>
PROMPT set to '\u@database-one \R:\m:\s [\d] session1>'
root@database-one 13:57:55 [(none)] session1>use gftest;
Database changed
root@database-one 13:58:31 [gftest] session1>select * from emp;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
+--------+------+---------+------------+--------+
5 rows in set (0.00 sec)
root@database-one 14:03:18 [gftest] session1>lock tables emp read;
Query OK, 0 rows affected (0.00 sec)
root@database-one 14:03:20 [gftest] session1>insert into emp values('陈实',31,9000,'2019-07-01',10);
ERROR 1099 (HY000): Table 'emp' was locked with a READ lock and can't be updated
可以看到，read锁定时只能读取，无法修改数据。
会话2登入，并修改提示符包含session2字样，然后对emp表读取。
root@database-one 14:04: [(none)]> prompt \u@database-one \R:\m:\s [\d] session2>
PROMPT set to '\u@database-one \R:\m:\s [\d] session2>'
root@database-one 14:05:04 [(none)] session2>use gftest;
Database changed
root@database-one 14:05:10 [gftest] session2>select * from emp;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
+--------+------+---------+------------+--------+
5 rows in set (0.00 sec)
root@database-one 14:05:20 [gftest] session2>lock tables emp read;
Query OK, 0 rows affected (0.00 sec)
可以看到，继续能够读取，同时也能加read锁。
[LOW_PRIORITY] WRITE锁：
持有锁的会话可以读写表。
只有持有锁的会话才能访问表。在释放锁之前，其他会话无法访问它。
当保持WRITE锁时，其他会话对表的锁请求被阻塞。
LOW_PRIORITY关键字已经作废。在以前的MySQL版本中，它影响锁定行为，但现在已经不是这样了。现在不推荐使用它，它的使用会产生一个警告。
会话1登入，并修改提示符包含session1字样，然后对emp表写入，可以进行，然后用lock tables给emp表加write锁定。
root@database-one 21:32: [(none)]> prompt \u@database-one \R:\m:\s [\d] session1>
PROMPT set to '\u@database-one \R:\m:\s [\d] session1>'
root@database-one 21:32:57 [(none)] session1>use gftest;
Database changed
root@database-one 21:33:07 [gftest] session1>select * from emp;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
+--------+------+---------+------------+--------+
5 rows in set (0.00 sec)
root@database-one 21:33:20 [gftest] session1>insert into emp values('陈实',31,9000,'2019-07-01',10);
Query OK, 1 row affected (0.01 sec)
root@database-one 21:34:50 [gftest] session1>lock tables emp write;
Query OK, 0 rows affected (0.00 sec)
会话2登入，并修改提示符包含session2字样，然后对emp表进行查询。
root@database-one 21:38: [(none)]> prompt \u@database-one \R:\m:\s [\d] session2>
PROMPT set to '\u@database-one \R:\m:\s [\d] session2>'
root@database-one 21:38:13 [(none)] session2>use gftest;
Database changed
root@database-one 21:38:21 [gftest] session2>select * from emp;
可以看到，表被以write方式锁定后，其它会话读取都无法进行，更不用提写入了。
UNLOCK TABLES显式释放当前会话持有的任何表锁。我们去session1中释放锁。
root@database-one 21:36:20 [gftest] session1>
root@database-one 21:45:29 [gftest] session1>unlock tables;
Query OK, 0 rows affected (0.00 sec)
root@database-one 21:45:43 [gftest] session1>
root@database-one 21:38:21 [gftest] session2>select * from emp;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
| 陈实 | 31 | 9000.00 | 2019-07-01 | 10 |
+--------+------+---------+------------+--------+
6 rows in set (7 min 11.08 sec)
root@database-one 21:45:43 [gftest] session2>
可以看到，session1在21:45:29后释放了锁，session2在21:45:43前就立即读取出了emp表的数据，整整排队等待了7分多钟，这些时间都被计入了这个SELECT的执行时间。
如果语句通过表名锁定，则不能使用别名。
root@database-one 21:57:54 [gftest] session1>lock table emp read;
Query OK, 0 rows affected (0.01 sec)
root@database-one 21:58:02 [gftest] session1>select * from emp as e;
ERROR 1100 (HY000): Table 'e' was not locked with LOCK TABLES
root@database-one 21:58:06 [gftest] session1>select * from emp;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
| 陈实 | 31 | 9000.00 | 2019-07-01 | 10 |
+--------+------+---------+------------+--------+
6 rows in set (0.00 sec)
如果使用别名锁定，则必须在语句中使用别名引用该表：
root@database-one 22:00:54 [gftest] session1>unlock tables;
Query OK, 0 rows affected (0.00 sec)
root@database-one 22:01:23 [gftest] session1>
root@database-one 22:01:25 [gftest] session1>lock table emp as e read;
Query OK, 0 rows affected (0.00 sec)
root@database-one 22:01:30 [gftest] session1>select * from emp;
ERROR 1100 (HY000): Table 'emp' was not locked with LOCK TABLES
root@database-one 22:01:34 [gftest] session1>select * from emp as e;
+--------+------+---------+------------+--------+
| ename | age | sal | hiredate | deptno |
+--------+------+---------+------------+--------+
| 郭军 | 27 | 8400.00 | 2019-12-08 | 10 |
| 刘杰 | 30 | 9100.00 | 2018-04-09 | 10 |
| 王艳 | 24 | 6000.00 | 2020-01-05 | 20 |
| 马丽 | 26 | 7200.00 | 2018-07-06 | 30 |
| 肖伟 | 29 | 8700.00 | 2017-05-28 | 30 |
| 陈实 | 31 | 9000.00 | 2019-07-01 | 10 |
+--------+------+---------+------------+--------+
6 rows in set (0.00 sec)
会话可以显式释放其锁，或者在某些条件下隐式释放锁。
会话可以使用UNLOCK TABLES显式释放其锁。
如果会话已经持有锁，还发出LOCK TABLES语句来获取新锁，那么在授予新锁之前，现有锁将被隐式释放。
如果会话开始事务(例如，使用START transaction)，则隐式执行UNLOCK TABLES，从而释放现有锁。
无论客户端会话的连接正常结束或异常终止，服务器均隐式释放该会话持有的所有表锁(事务性和非事务性)。
LOCK TABLES和UNLOCK TABLES与事务的交互如下：
LOCK TABLES不是事务安全的，在尝试锁定表之前隐式提交任何活动事务。
UNLOCK TABLES隐式提交任何活动事务，前提是LOCK TABLES已用于获取表锁。例如，在以下语句集中，UNLOCK TABLES释放全局读取锁，但不提交事务，因为没有有效的表锁：
FLUSH TABLES WITH READ LOCK;
START TRANSACTION;
SELECT ... ;
UNLOCK TABLES;
开始事务(例如，使用START transaction)隐式提交任何当前事务并释放现有表锁。
对事务表(如InnoDB TABLES)使用LOCK TABLES和UNLOCK TABLES的正确方法是，以SET autocommit=0(不是START transaction)后跟LOCK TABLES开始事务，并且在显式提交事务之前不调用UNLOCK TABLES。例如，如果需要写入表t1并读取表t2，可以执行以下操作：
SET autocommit=0;
LOCK TABLES t1 WRITE, t2 READ, ...;
... do something with tables t1 and t2 here ...
COMMIT;
UNLOCK TABLES;
ROLLBACK不会释放表锁。
综上所述，当我们需要独占式的对表做一些运维操作时，使用LOCK TABLES和UNLOCK TABLES是个很不错的选择。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
