一行数据引发的阻塞：GTop 现场演示 GaussDB 锁等待与慢 SQL 排查

两个会话，同一行数据。

第一个会话开启事务并更新数据，第二个会话再次更新同一行时，等待出现了。

这次，我们邀请到 郑成龙老师把这个锁等待场景现场做了出来，并通过 GTop 的 Block、Wait 和 Session 页面，展示了等待会话、阻塞会话及其 SQL。

现场又切换到 Top SQL、Statement History 和 Storage 等页面，演示了慢 SQL、执行计划和存储信息的查看方式。

GTop 的设计灵感来自 DB2Top，这场分享也从产品定位、连接配置和总览监控开始，逐步展开到具体的排查操作。

🌟 先看边界：GTop 专门解决什么问题？

郑老师先给数据库问题分了类。

日常处理数据库问题时，可能涉及安装部署、故障处理、产品升级，也可能涉及数据库内部性能优化。GTop 聚焦的是最后一类：性能优化相关场景。

现场随后演示了连接和启动方式：

远程连接，可以指定 IP、端口、用户和数据库；

本地连接，可以直接连接数据库实例；

远程连接用户需要具备超级管理员权限；

启动参数可以通过gtop -h查看。

工具也支持主备节点连接。现场连接备节点后，界面中的primary状态显示为false。郑老师介绍，备节点的连接方式与主节点基本一致。

另外，GTop 当前提供面向 x86 和 ARM 的版本。

📊 总览界面：每 2 秒刷新一次数据库状态

连接数据库并选择目标库后，现场进入了 GTop 总览界面。

这个界面每 2 秒自动刷新一次，刷新周期也可以通过参数设置。屏幕上集中展示了以下信息：

集群组成和主备节点状态；

总连接数；

活跃连接数；

idle空闲连接；

idle in transaction未提交事务；

锁等待情况；

TPS 和 QPS；

缓冲池命中率；

插入、更新、删除和查询等语句的行数变化。

现场创建事务并更新数据后，总览界面中出现了idle in transaction和锁等待状态。

这些状态也就直接成为后面锁等待演示的入口。

🔥 锁等待现场：谁在等，谁在挡路？

为了制造锁等待场景，郑老师现场创建了一张测试表，然后在两个会话中更新同一行数据。

第一个会话开启事务并更新数据，第二个会话更新同一行时进入等待。

随后，现场切换到 GTop 的不同页面：

Block 视图可以查看等待 PID、阻塞 PID、等待状态和等待的 SQL；

Wait 视图可以从等待事件角度查看同一场景；

Session 视图可以查看idle、active、idle in transaction等会话状态；

在会话列表中可以使用上下键选择会话，按回车进入详情；

进入会话后，可以查看与该会话有关的 SQL、执行计划和索引建议。

现场还特别演示了快捷键帮助。按H可以打开帮助和快捷键说明，其中列出了可用快捷键，以及 Block、Wait 等页面入口。

在这一段里，现场把“等待会话是谁、阻塞会话是谁、双方执行的 SQL 是什么”直接展示了出来。

⚡ Kill 还是提交？现场这样处理

锁等待不只有一种处理方式。

演示中，现场执行了 Kill 操作，并要求再次确认后才结束异常会话。同时，郑老师也明确提到，锁等待场景不一定都要 Kill，可以通过提交事务解决。

后面的演示中，现场也操作了事务提交。

因此，这场直播实际展示了两种处理动作：需要终止会话时使用 Kill，并在操作前二次确认；能够通过事务提交解除阻塞时，也可以选择提交。

🔍 Top SQL：按 CPU、I/O 和内存找“重量级选手”

锁等待之后，现场进入 Top SQL 页面。

这里展示的是最近 10 分钟内 SQL 的累计情况，并支持按 CPU、I/O 和内存进行排序。

郑老师结合排查场景说明了不同排序方式：

CPU 使用较高时，可以按 CPU 排序查看 Top SQL；

出现 I/O 等待时，可以按 I/O 排序查看 Top SQL；

也可以按内存排序，不过现场提到，内存相关问题相对少一些。

现场分别查看了不同维度下的排序结果。

🧭 执行计划：正在执行的 SQL 和历史 SQL 分开看

找到重点 SQL 后，下一步就是查看执行计划。

现场演示了两种获取路径：

对正在执行的 SQL，通过gs_get_explain获取执行计划；

对已经执行完成的 SQL，从 Statement History 中获取当时的执行计划。

获取执行计划后，界面还可以显示索引建议。

直播中将这种方式与普通的EXPLAIN ANALYZE方式进行了对比，并说明通过 Statement History 可以获取已经执行完成的 SQL 所对应的计划。

这里还有一个与慢 SQL 阈值有关的细节。

举例说明：如果生产环境将慢 SQL 阈值设置为 3 秒，那么 3 秒以内完成的 SQL 不会出现在相应的历史执行计划中。

所以，查看历史慢 SQL 和执行计划时，阈值设置也会影响最终能看到的数据。

🧰 Session 与 Storage：再补两块上下文

除了锁等待和 Top SQL，现场还演示了 Session 与 Storage 页面。

Session 页面可以查看一个会话最近执行过的 SQL。现场演示了最后一组 SQL 和最后若干条 SQL 的筛选方式。

Storage 页面则按行数展示较大的表，并显示死元组死亡率。郑成龙介绍，这些信息可以用于后续的数据归档或清理。

现场还查看了表空间、缓冲池、复制延迟和健康状态等页面。直播中提到，日常性能排查最常使用的是靠前的几个页面，后面的页面相对使用较少。

⚠️ 现场遇到的 Schema 报错

这次演示并不是一路无报错。

从某个会话中获取执行计划时，界面因为未获取 Schema 而报错。

问题原因表示：

工具没有获取 Schema；

正常情况下可以通过该入口获取执行计划；

会在之后修复这个问题。

这一段也把工具的现场表现和后续待修复项直接展示了出来。

💡 写在最后

从每 2 秒刷新的总览界面，到双会话锁等待演示，再到 Top SQL、Statement History 执行计划和 Storage 页面，这次直播完整展示了 GTop 在一次性能排查演示中的使用过程。

其中，现场直接呈现了锁等待双方 PID 和 SQL、Kill 的二次确认、事务提交、按 CPU/I/O/内存排序、当前与历史执行计划，以及慢 SQL 阈值带来的影响。

感谢郑老师的分享！如果想获取完整 PPT 和视频回放，或者想进群深入交流，欢迎关注 IFClub 视频号与公众号，我们群里见！

💬互动话题：

你在日常数据库排查中，遇到过最难定位的问题是什么？是锁等待、慢 SQL，还是执行计划变化？

（注：本文根据 IFClub 2026-10-31 郑成龙老师直播分享整理，完整回放可关注“IF-论坛”视频号观看，PPT可以点击“阅读原文”查看。）