insert语句忽快忽慢该从什么角度分析哪

在ocp监控中发现有些insert语句,有的时候快有的时候慢,想知道这种该从什么角度去分析哪?按正常来讲,insert不应该慢啊。

1 个赞

慢SQL日志中看看,耗时在哪里,在看看那个时间是不是转储时间,内存不足,写入限速。

业务发布新版本,出现新的 SQL 逻辑

业务有新发布上线时,会有新 SQL 产生,在有些情况下可能存在一些未经 review 的慢 SQL 在生产上占用了过多资源,影响了核心业务。此时需要排查数据库中的慢 SQL 来定位问题所在,并进行后续优化处理。

  1. 通过 OCP 查找慢 SQL。可以在 OCP 的 TOP SQL 页面查看最近一段时间耗时、执行次数最高的查询,从高到低进行排序,对于计划走错的 SQL直接在线绑定,具体操作请参见 可疑 SQL 诊断 ;对于需要限流的 SQL,需要结合业务研发的确认信息,定位可以进行限流的SQL。
  2. 在命令行查找慢 SQL。
  3. 查询特定租户下消耗 CPU 最多的 top sql。
SELECT
 sql_id,
  avg(execute_time) avg_exec_time,
  count(*) cnt,
  avg(execute_time - TOTAL_WAIT_TIME_MICRO) cpu_time,
RETRY_CNT,QUEUE_TIME,IS_HIT_PLAN
FROM
 OCEANBASE.V$OB_SQL_AUDIT
WHERE
  tenant_id = 1002 
GROUP BY 
 1
ORDER BY 
 (avg_exec_time * cnt) desc
limit
 5;

说明

  • 其中 EXECUTE_TIME 值,如果值过大,考虑存在等待事件或逻辑读次数异常多。
  • RETRY_CNT 字段即 retry 次数,如果次数很多,则可能有锁冲突或切主等情况。
  • QUEUE_TIME 过大,则表明 CPU 资源不够用。
  • GET_PLAN_TIME 为获取执行计划的时间,如果如果时间很长,一般会伴随 IS_HIT_PLAN=0,表示没有命中 plan。
  1. 其他相关查询。OceanBase 提供两张虚拟表 V$OB_SQL_AUDITGV$OB_SQL_AUDIT 记录最近一段时间 SQL 执行历史,V$OB_SQL_AUDIT 存储本机的 SQL 执行历史,GV$OB_SQL_AUDIT 存储整个集群的 SQL 执行历史。可以根据需要进行相关查询。
  2. 查询 GV$OB_SQL_AUDIT 表,如查询某租户执行时间大于1s (1000000微秒)的 SQL。
SELECT * FROM oceanbase.GV$OB_SQL_AUDIT WHERE tenant_id= <tenantid> AND elapsed_time> 1000000 limit 10;
  1. 查询 SQL 执行时间按秒分布的直方图。
SELECT round(elapsed_time/1000000), count(*) FROM oceanbase.V$OB_SQL_AUDIT WHERE tenant_id = <tenant_id> GROUP BY  1;
  1. 在 OceanBase 日志中查找慢 SQL。OceanBase 中 SQL 执行时间超过 trace_log_slow_query_watermark (系统参数)的,在 observer 日志中都会打印 slow query 消息,该参数默认值为 100ms。可以通过 observer 日志查找慢 SQL。这种方式没有上述两种方法高效直观,但在一些情况下也有助于一些问题的问题,例如当 sql_audit 中的缓存已经淘汰时。记录慢 SQL 日志的位置:/home/admin/oceanbase/log
  2. 看日志中所有的 slow query。fgrep '[slow query]' observer.log |sed -e 's/|/\n/g' | more
  3. 根据 trace_id 查询某个 slow query。fgrep "<trace_id>" observer.log |sed -e 's/|/\n/g' | more

在observer.log里搜索慢SQL

https://www.oceanbase.com/docs/common-oceanbase-database-cn-10000000001699942

如果topSql里重试次数 >0 ,大概率因为锁冲突