LOCK · PostgreSQL 中文文档 9.3

# LOCK ## Name LOCK -- 锁定一个表 ## Synopsis ``` LOCK [ TABLE ] [ ONLY ] _name_ [ * ] [, ...] [ IN _lockmode_ MODE ] [ NOWAIT ] 这里的`_lockmode_`可以是下列之一： ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE ``` ## 描述 `LOCK TABLE`获取一个表级锁，必要时等待任何冲突的锁释放。如果声明了`NOWAIT`，那么`LOCK TABLE` 并不等待它所需要的锁：如果无法立即获取该锁，那么该命令退出并且发出一个错误信息。如果成功获取了这个锁，那么它就会在当前事务的余下部分一直保持。没有`UNLOCK TABLE`命令；锁总是在事务结尾释放。在为那些引用了表的命令自动请求锁的时候，PostgreSQL 总是尽可能使用最小限制的锁模式。`LOCK TABLE`是为你在需要更严格的锁的场合提供的。例如，假设一个应用在"读已提交"隔离级别上运行事务，并且它需要保证在表中的数据在事务的运行过程中都存在。要实现这个目的，你可以在查询之前对表使用`SHARE`锁模式进行锁定。这样将保护数据不被并发修改并且为任何更进一步的对表的读操作提供实际的当前状态的数据，因为`SHARE`锁模式与任何写操作需要的`ROW EXCLUSIVE`模式冲突，并且你的`LOCK TABLE` `_name_` IN SHARE MODE 语句将等到所有当前持有`ROW EXCLUSIVE`模式的锁提交或回卷后才执行。因此，一旦你获得该锁，那么就不会存在未提交的写操作，并且其他人只能在你释放锁之后才能再次获取锁。如果运行在`可重复读`或`可串行化`隔离级别实现类似的效果的时候，你必须在执行任何`SELECT`或数据修改语句之前运行一个`LOCK TABLE`语句。一个`可重复读`或`可串行化`事务的数据图像将在其第一个`SELECT` 或者数据修改语句开始的时候冻结住。稍后的`LOCK TABLE`将仍然阻止并发的写，但它不能保证事务读取的东西对应最近提交的数值。如果一个此类的事务准备修改一个表中的数据，那么应该使用`SHARE ROW EXCLUSIVE`锁模式，而不是`SHARE`模式。这样就保证任意时刻只有一个此类的事务运行。不这样做就可能会死锁：当两个并发的事务可能都请求`SHARE`模式，然后试图更改表中的数据时，两个事务在实际执行更新的时候都需要`ROW EXCLUSIVE`锁模式，但是它们无法再次获取这个锁。请注意，一个事务自己的锁是从不冲突的，因此一个事务可以在持有`SHARE` 模式的锁的时候请求`ROW EXCLUSIVE`模式(但是不能在任何其它事务持有`SHARE` 模式的时候请求)。为了避免死锁，所有事务应该保证以相同的顺序对相同的对象请求锁，并且，如果涉及多种锁模式，那么事务应该总是最先请求最严格的锁模式。有关锁模式和锁定策略的更多信息，请参考[Section 13.3](#calibre_link-1161)。 ## 参数 `_name_` 要锁定的现存表的名字(可以有模式修饰)。如果在表名前声明了`ONLY`，那么只有那一个表被锁定。如果没有声明`ONLY`，那么该表和它的所有后代表（如果有）都被锁定。可选的，`*` 可以在表名后面指定，明确表明包含后代表。命令`LOCK TABLE a, b;`等效于`LOCK TABLE a; LOCK TABLE b;`。表是按照`LOCK TABLE`命令中声明的顺序一个接一个顺序上锁的。 `_lockmode_` 锁模式声明这个锁和哪些锁冲突。锁模式在[Section 13.3](#calibre_link-1161)里描述。如果没有声明锁模式，那么使用最严格的模式`ACCESS EXCLUSIVE`模式。 `NOWAIT` 声明`LOCK TABLE`不去等待任何冲突的锁释放：如果无法不等待立即获取所要求的锁，那么事务退出。 ## 注意 `LOCK TABLE ... IN ACCESS SHARE MODE`需要在目标表上有`SELECT`权限。所有其它形式的`LOCK`需要表级别的`UPDATE`，`DELETE` 或`TRUNCATE`权限。 `LOCK TABLE`在事务块的外部没什么用：锁依然被持有直到声明结束。因此如果`LOCK`在一个事务块外面使用，PostgreSQL会报告一个错误。使用[BEGIN](#calibre_link-493)和[COMMIT](#calibre_link-494)（或[ROLLBACK](#calibre_link-495)) 定义一个事务块。 `LOCK TABLE`只处理表级的锁，因此那些有`ROW`字样的锁都是用词不当。这些模式名字通常应该理解为用户试图在一个被锁定的表中获取行级的锁。同样， `ROW EXCLUSIVE`模式也是一个可共享的表级锁。一定要记住，只要是涉及到`LOCK TABLE`，那么所有锁模式都有相同的语意，区别只是它们与哪种锁冲突的规则。有关如何获取一个行级锁的信息，请参阅 [Section 13.3.2](#calibre_link-1162)和`SELECT`命令参考页的 [_锁定子句_](#calibre_link-1058)子句信息。 ## 例子演示在往一个外键表上插入时在有主键的表上使用`SHARE`的锁： ``` BEGIN WORK; LOCK TABLE films IN SHARE MODE; SELECT id FROM films WHERE name = 'Star Wars: Episode I - The Phantom Menace'; -- 如果记录没有返回则 ROLLBACK INSERT INTO films_user_comments VALUES (_id_, 'GREAT! I was waiting for it for so long!'); COMMIT WORK; ``` 在执行删除操作时对一个有主键的表进行`SHARE ROW EXCLUSIVE`锁： ``` BEGIN WORK; LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE; DELETE FROM films_user_comments WHERE id IN (SELECT id FROM films WHERE rating < 5); DELETE FROM films WHERE rating < 5; COMMIT WORK; ``` ## 兼容性在 SQL 标准里面没有`LOCK TABLE`，可以使用`SET TRANSACTION` 来声明当前事务的级别。PostgreSQL也支持这个，参阅[SET TRANSACTION](#calibre_link-507)获取详细信息。除了`ACCESS SHARE`, `ACCESS EXCLUSIVE`, `SHARE UPDATE EXCLUSIVE` 锁模式外，PostgreSQL锁模式和`LOCK TABLE` 语句都与那些在Oracle里面的兼容。