LOCK有一个documented behavior：它在表上获得了排他锁，因此其他会话或事务都不能对该表做任何操作。

如果您想验证此行为，请按以下步骤操作：

1. 打开与数据库的连接，并针对测试表调用begin和lock命令。
2. 打开与数据库的第二连接，并尝试对该表执行select。
3. 请等待，直到选择返回或您确信LOCK的行为与文档相同。
4. 在第一个会话中执行rollback，这样就不会永久锁定表。

更新

根据您的评论，我认为您对交易的工作方式有误解：

• 启动事务时，Redshift会分配一个事务ID，并标记该事务更改的每一行。
• 在事务中更新表时选择读取表的选择将看到“已提交的数据快照”（来自链接上方的引用），而不是事务中正在更新的行。
li> 尝试更新正在由事务更新的表的
• INSERT / UPDATE / DELETE将阻塞，直到事务完成为止（请参见doc，请注意，此行为与您看到的情况有些不同，例如，MySQL）。
• 当您提交/回滚事务时，任何 new SELECT都将使用更新的数据。在交易期间启动的所有SELECT都将继续使用旧数据。

鉴于这些规则，几乎没有理由使用显式LOCK语句。您的示例更新不带锁会在要更新的表上放置写锁（以确保没有其他查询可以同时更新它），并且将使用表的快照正在阅读。

如果做使用LOCK，则在更新过程中，您将阻止所有试图从表中进行SELECT的查询。您可能会想这就是您想要的，以确保您的用户只能看到最新的数据，但是请考虑一下，在更新之前启动的所有SELECT仍会看到旧的数据。

我之所以使用LOCK语句的 only 原因是，如果您需要保持一组表之间的一致性（嗯，如果您陷入了死锁，但您没有指出那个）：

begin;
lock TABLE1;
lock TABLE2;
lock TABLE3;
copy TABLE1 from ...
update TABLE2 select ... from TABLE1
update TABLE3 select ... from TABLE2
commit;

在这种情况下，请确保TABLE1，TABLE2和TABLE3始终保持一致：对它们中的任何一个的查询将显示相同的信息。但是请注意，在锁定之前启动的SELECTS将成功执行，并在任何更新之前显示数据。并且在事务完成之时开始在事务中执行的SELECT才真正执行。如果您的用户在工作日中间发生这种情况，则可能会不满意。