慢SQL无处可逃！手把手教你用GV$OB_SQL_AUDIT快速定位性能瓶颈

培训 & 考证
#1

生产环境突然变慢，别慌！OceanBase内置的SQL审计视图就是你的“监控录像”，三步揪出元凶。

1. 找到最近最慢的10条SQL

sql

SELECT SQL_ID, QUERY_SQL, ELAPSED_TIME/1000000 ELAPSED_SEC, EXECUTE_TIME, QUEUE_TIME, NET_WAIT_TIME, IO_WAIT_TIME FROM oceanbase.GV$OB_SQL_AUDIT WHERE REQUEST_TIME > DATE_SUB(NOW(), INTERVAL 10 MINUTE) ORDER BY ELAPSED_TIME DESC LIMIT 10;

2. 分析关键字段含义

  • ELAPSED_TIME ：总耗时（微妙），越大越慢
  • EXECUTE_TIME ：实际执行耗时
  • QUEUE_TIME ：排队等待耗时（高说明并发冲突）
  • IO_WAIT_TIME ：磁盘IO等待（高说明索引缺失）
  • NET_WAIT_TIME ：网络传输耗时（分布式查询看这个）

3. 定位具体慢在哪

sql

– 查看某条SQL的完整执行计划 SELECT OPERATOR, OBJECT_NAME, ROWS, COST FROM TABLE(DBMS_XPLAN.DISPLAY_AUDIT(‘你的SQL_ID’));

小技巧 ：如果QUEUE_TIME 占比高，查锁等待；IO_WAIT_TIME 高，加索引；NET_WAIT_TIME 高，优化分区键。

【标签】 #性能诊断 #SQL审计 #慢查询 #运维实战

6 个赞
#2

学习并收藏了

2 个赞
#3

学习了

2 个赞
#4

比较实用

2 个赞
#5

学习了

1 个赞
#6

学习了

#7

记录学习一下

#8
  • 如果 QUEUE_TIME 占比高：检查锁等待、并发设置，考虑优化业务逻辑或拆分任务。
  • 如果 IO_WAIT_TIME 高：检查执行计划，添加合适的索引，避免全表扫描。
  • 如果 NET_WAIT_TIME 高：在分布式场景下，优化分区键设计，减少跨节点数据传输。