乾貨分享｜快速定位UXDB中CPU高負荷的SQL語句

導讀  

觸發器造成死鎖、作業多且頻繁、中間表的大量使用、遊標的大量使用、索引的設計不合理、事務操作頻繁、SQL語句設計不合理，都會造成查詢效率低下、影響伺服器效能的發揮。本期分享，我們將為大家示範如何快速定位資料庫中CPU佔用高的SQL語句。

TOP監控

檢視佔用CPU高的uxdb程式，並獲取該程式的ID號，如圖該id號為28214。

 

 

查詢高佔用SQL

切換到uxdb使用者，uxsql連線到資料庫，執行如下查詢語句。

程式id procpid ：28214。

SELECT procpid, START, now() - START AS lap, current_query  FROM ( SELECT backendid, ux_stat_get_backend_pid (S.backendid) AS procpid,

ux_stat_get_backend_activity_start (S.backendid) AS START,ux_stat_get_backend_activity (S.backendid) AS current_query  FROM (SELECT

ux_stat_get_backend_idset () AS backendid) AS S) AS S WHERE current_query <> '<IDLE>' and procpid=28214 ORDER BY lap DESC;

 procpid |             start             |       lap        |                                                  current_query                                      ---------+-------------------------------+------------------+-----------------------------------------------------------------------------------------------------

   28214 | 2021-04-04 11:10:00.210575+08 | -00:00:00.000429 | insert into test values (random()*10000, random()*10000, random()*10000,md5(random()::text), CURRENT

_TIMESTAMP);

(1 row)

procpid：程式id 如果不確認程式ID，將上面的條件去掉，可以逐條分析 start：程式開始時間 lap：經過時間 current_query：執行中的sql。

怎麼停止正在執行的SQL？

SELECT ux_cancel_backend(28214);

 ux_cancel_backend

-------------------

 t

(1 row)

檢視該sql的執行計劃

使用explain analyze + sql語句的格式。

explain analyze insert into test values (random()*10000, random()*10000, random()*10000,md5(random()::text), CURRENT_TIMESTAMP);

          QUERY PLAN  

 Insert on test  (cost=0.00..0.05 rows=1 width=52) (actual time=0.142..0.142 rows=0 loops=1)

   ->  Result  (cost=0.00..0.05 rows=1 width=52) (actual time=0.066..0.066 rows=1 loops=1)

 Planning time: 0.058 ms

 Execution time: 0.199 ms

(4 rows)

/*lanning time: 表明了生成查詢計劃的時間

Execution time:表明了實際的SQL 執行時間，其中不包括查詢計劃的生成時間*/

分析

本例用於說明查高佔用CPU的SQL方法，SQL合理性分析在此不做重要，本例主要是批量插入資料對CPU造成的壓力。