从一个锁表问题理解hive锁机制

鉴于之前类似的反馈，检查SQL中涉及的表的锁，

找到了几个共享锁来解锁该表。

然而，当重新执行sql时，仍然有一个锁。sql主干如下(查出分区表B中某一天的用户，历史表A中不存在，执行前已经添加了add partition)。

发现不仅不能插入，而且来自语句的select user_id也不能执行。因为是测试表，所以重新构建(事后估计多个分区被锁，有X个锁，只解锁表无法递归解锁每个分区)。重建后，选择辨别...这整个语句将被GC内存超出，它将被重写为如下框架(窗口函数替换distinct，外部连接替换in):

所以select语句可以运行，但是整个sql仍然锁定表。

看资料。

蜂巢锁，那些东西

公文

blogs.com/barneywill/p/10185577.html

发现select语句..t1分区p1需要t1和t 1上的S锁，因此选择整个分区表需要所有分区的S锁。

回到语句，join操作依赖于表A的S锁，但最终会被写入表A的一个新分区，并添加一个X锁，导致死锁。因此，有必要使要写入表A的分区不带S锁:

成功执行。

另外，设置配置单元参数set hive。SQL执行前support.concurrency = false可以强制忽略锁，但为了数据完整性，不建议执行此操作。