如何分析一条SQL语句的时间都花费在哪些模块上？

[AntTech_MO9IXW]

如图是benchmark压测的语句。可以看到，每条SQL的execute_time都非常小， 但最终的elapsed_time都高出好几个数量级。

问题，如何分析一条SQL语句的时间都花费在了哪些模块上？

[云深月隐]

还是这个视图，查询其他列
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000752086#2-title-GV$OB_SQL_AUDIT%20字段说明

[靖顺]

我之前写过一篇关于sql_audit的解释博客，可以看看：OceanBase 社区

[AntTech_MO9IXW]

中间这些消耗的时间都已经考虑到了。 excute_time 再加上这些中间过程消耗的时间，也远远小于elapsed_time.

[靖顺]

把RETRY_CNT重试次数打出来看看

[AntTech_MO9IXW]

[靖顺]

把你查询sql_audit的语句也贴一下吧，图片中的sql隐藏了后半部分

[AntTech_MO9IXW]

发现一个问题： 这种elapsed_time 比 execute_time 高出非常多的SQL， 基本上都是 DML语句。

如果你所提示的，看retry_cnt指标，这些SQL的retry_cnt基本上都是3次。 这应该是锁等待。

查了gv$ob_locks, 的确有一些锁等待，但这些锁等待都是变化的，也即没有长时间的锁等待， 这种应该属于正常情况。

那么， 针对这种情况， 如何能进一步优化？

[靖顺]

retry_cnt这种多次的话确实很大概率是锁等待，可以用obdiag来分析一下是否存在锁冲突。
https://www.oceanbase.com/docs/common-obdiag-cn-1000000000791120

obdiag rca list 可以看到根因分析的场景
obdiag rca run --scene=lock_conflict 可以直接分析集群中是否存在锁冲突

另外：如果真的有锁的话得看看dml语句这块是不是不够合理，为啥会产生锁，是不是需要改改语句

[AntTech_MO9IXW]

lock.txt (41.6 KB)

附件是obdiag rca run --scene=lock_conflict的报告，请帮忙看看，谢谢！

[渠磊]

你好，我是obdiag的开发同学，这边已经看到了上传的结果，

1. 发现存在多个锁，上传记录里有24个锁，
2. 触发到了obdiag的bug，暂时无法深入，预计近日修复，届时可以通过obdiag update热更新修复

[AntTech_MO9IXW]

好，谢谢！ 等obdiag更新后，我再继续收集这个问题的日志。