在遇到迟迟无法执行完成的SQL时,通常有以下几种常见情况:
1. 锁堵塞
1)先通过show processlist命令,查看SQL的状态,观察其是否为"checking permission",如果是,则大概率是锁堵塞。如果不是,则不是锁堵塞。
2)当是时,通过gcadmin showlock命令,查看当前集群的锁信息。
a. 记录processlist中,该SQL的会话ID


b.在showlock信息中,通过会话ID,确认该SQL在等待哪个锁。比如下图,就查出了ID=269的SQL在等待哪个锁


c.在showlock信息中,搜索该锁在被哪条SQL持有。


d.回到processlist信息,确认ID=342的SQL的执行情况。判断其是否在正常执行,是否可以kill掉以释放锁。


2. 笛卡尔积
1)扫描各节点的磁盘情况,观察是否存在磁盘突然增长的情况。因为笛卡尔积SQL会导致出现大量的临时数据占用磁盘。
a.在各节点上du -sh ../gnode/tmpdata
b.若出现某节点空间明显高于其他节点的情况,则为异常
2)前往异常节点的tmpdata目录下,查看文件名称,文件最多的文件名称开头即为会话ID


3)gncli登录该节点,通过会话ID,关联到其在gcluster层的会话id。在GNode层SQL语句的hint中会带有其在gcluster层的会话id


4)登录gcluster节点,根据2806155查看SQL并分析SQL。
3. 慢节点堵塞
1)通过gcluster层的会话ID,前往各GNode节点,查看该SQL在各GNode层的执行情况。
2)若该SQL,目前只有一个节点在执行,则可能因为木桶理论导致SQL被堵塞
3)观察该GNode节点的SQL情况,判断其积压的SQL数量是不是明显高于其他节点
4)观察该节点的资源历史占用情况
5)分析慢节点原因并考虑是否重启该节点