1查看该SQL的执行节点IP和对应的ID
如 ：
|269 | root | localhost | testdb | Query | 16 | checking permissions | alter table t1 add column name varchar(100) |
上面这一行的第一个字段【269】就是SQL的id，第三个字段【localhost】就是对应的ip，这里是本机，如果是其他节点会显示对应的ip
2.通过gcadmin showlock 查看对应id的集群锁情况：
$gcadmin showlock | grep 269
您或许会得到多组结果，找出第五个字段为【FALSE】的哪一行
如：| vc00001.testdb.t1.meta_lock |10.0.2.101|269(LWP:21694)|20211222145941|FALSE | S |
由上面的语句可以判断出为vc00001.testdb.t1.meta_lock是这个锁
3.查看锁的持有者
继续通过gcadmin showlock查看锁持有者的情况
$ gcadmin showlock | grep vc00001.testdb.t1.meta_lock
| vc00001.testdb.t1.meta_lock |10.0.2.101|342(LWP:15618)|20211222145916| TRUE | E |
由上面语句可以判断出vc00001.testdb.t1.meta_lock这个锁的持有者为10.0.2.101，且这个用户在342这个进程上锁。
4.查看进程锁的任务
登录回到集群进行show processlist;找到锁进程对应的哪一行，此例子对应的为342
如：| 342 | root | localhost | testdb | Sleep | 613 | | NULL|
如上面可以看到342的状态为Sleep（空闲）状态。
根据发起者信息，可以继续排查该业务连接是否正常。 如果该业务就是需要长时间持有锁，那就只能等待。 如果业务异常，比如机器意外宕机， jvm卡住等， 可以考虑kill掉这个不正常Sleep状态的SQL 进程来释放锁。
5.【非必要不执行】kill锁进程：
gbase> kill 342
