1.锁表原因
a.锁表发生在insert update 、delete 中

b.锁表的原理是 数据库使用独占式封锁机制，当执行上面的语句时，对表进行锁住，直到发生commite 或者 回滚 或者退出数据库用户

c.锁表的原因
第一、 A程序执行了对 tableA 的 insert ，并还未 commite时，B程序也对tableA 进行insert 则此时会发生资源正忙的异常 就是锁表
第二、锁表常发生于并发而不是并行（并行时，一个线程操作数据库时，另一个线程是不能操作数据库的，cpu 和i/o 分配原则）

d.减少锁表的概率
1》减少insert 、update 、delete 语句执行 到 commite 之间的时间。具体点批量执行改为单个执行、优化sql自身的非执行速度
2》如果异常对事物进行回滚
1.Hive中定义了两种锁的模式：
共享锁（S）和排它锁（X），顾名思义，多个共享锁(S)可以同时获取，但是排它锁(X)会阻塞其它所有锁。

如果select一张表，这张表则会进入shared模式，增加、插入、删除、修改数据和修改表名等操作都会在shared锁被释放之后再执行，会一直等待。

如果插入、删除、修改数据则进入Exclusive锁模式，进入排他锁模式之后不允许增删改操作，会报错。
2.查看表被锁的情况：
show locks table_name;
3.解锁
a.unlock table table_name; – 解锁表
b.unlock table table_name partition(dt=‘2020-06-27’); – 解锁表中某个分区

这个问题，没有完全彻底的解决方案，这与hive本身的锁机制有很大关系，从cloudera官方论坛里的讨论也可以看出，
无非就是这么四种：（在unlock不掉锁的情况下）

  1. 在脚本中添加以下配置
    关闭锁机制：set hive.support.concurrency=false
    （默认为true）
  2. 有人建议，直接去删除掉 zookeeper中的 lock锁节点，但是还没有人亲身测试过，且直接删除节点的风险很大。
  3. 通过show locks extended； 查到语句复制到hue然后执行通过，解锁。
  4. 查询hive metastore数据库，如果里边有锁记录，删除记录，解锁。但是就我的观察看，这个锁记录可能在老版本中是存放在metastore数据库的，
    新版本基本上都应该在zookeeper节点里边，所以，此方法可能只是部分版本有效。