1、什么是Unique SQL

用戶執(zhí)行SQL語句時(shí)，每一個(gè)SQL語句文本都會(huì)進(jìn)入解析器（Parser），生成“解析樹”（parse tree）。遍歷解析樹中各個(gè)結(jié)點(diǎn)，忽略其中的常數(shù)值，以一定的算法結(jié)合樹中的各結(jié)點(diǎn)，計(jì)算出來一個(gè)整數(shù)值，用來唯一標(biāo)識(shí)這一類SQL，這個(gè)整數(shù)值被稱為Unique SQL ID，Unique SQL ID相同的SQL語句屬于同一個(gè)“Unique SQL”。

例如，用戶先后輸入如下兩條SQL語句：

select * from t1 where id = 1;
select * from t1 where id = 2;

這兩條SQL語句除了過濾條件的常數(shù)值不同，其他地方都相同，由此生成的解析樹的拓?fù)浣Y(jié)構(gòu)完全相同，故Unique SQL ID也相同。因此兩條語句屬于如下同一個(gè)Unique SQL：

select * from t1 where id = ?;

GaussDB內(nèi)核會(huì)對(duì)所有上面形式的SQL語句匯總統(tǒng)計(jì)信息，通過視圖呈現(xiàn)給用戶。通過這種方式，可以排除一些無關(guān)的常量值的干擾，獲得某一類SQL語句的統(tǒng)計(jì)數(shù)據(jù)，為性能分析和問題定位提供數(shù)值依據(jù)。

注意，對(duì)于Unique SQL ID的計(jì)算，只會(huì)排除常數(shù)值，而不會(huì)排除其他的差異。例如，SQL語句“select * from t2 where id = 1;” 與上面的SQL不屬于同一個(gè)Unique SQL，不同用戶，從不同的CN節(jié)點(diǎn)執(zhí)行的相同的SQL語句也不屬于同一個(gè)Unique SQL。

2、Unique SQL如何統(tǒng)計(jì)

收到SQL請求后，GaussDB內(nèi)核首先算出其Unique SQL ID。如果該Unique SQL ID已存在，則直接更新相關(guān)的統(tǒng)計(jì)信息。如果不存在，首先創(chuàng)建一個(gè)Unique SQL，然后再更新統(tǒng)計(jì)信息，如下圖所示：

Unique SQL的統(tǒng)計(jì)信息包括執(zhí)行次數(shù)，響應(yīng)時(shí)間，Cache/IO數(shù)量，行活動(dòng)和時(shí)間分布等信息，可以通過如下兩個(gè)視圖查詢：

• gs_instr_unique_sql
• pgxc_instr_unique_sql

前者顯示當(dāng)前CN（Coordinator Node）節(jié)點(diǎn)（執(zhí)行當(dāng)前SQL命令的節(jié)點(diǎn)）上的Unique SQL信息，后者顯示系統(tǒng)中所有CN節(jié)點(diǎn)上的Unique SQL信息。兩個(gè)視圖的格式相同，均由下表中的字段組成：

3、如何使用Unique SQL

使用Unique SQL功能需要打開以下變量開關(guān)：

• enable_resource_check（默認(rèn)為on）
• track_counts（默認(rèn)為on，影響行活動(dòng)和Cache/IO相關(guān)字段）

此外還需要將instr_unique_sql_count設(shè)為正整數(shù)。該變量默認(rèn)為0，且不能在gsql會(huì)話中修改，需要通過SIGHUP的方式設(shè)置，例如：

gs_guc reload -Z coordinator -D /path/to/coordinator1/ -c "instr_unique_sql_count=20" > /dev/null

instr_unique_sql_count參數(shù)決定了系統(tǒng)收集的unique sql的數(shù)量。當(dāng)收集的unique數(shù)量達(dá)到這個(gè)數(shù)后，新的sql不再被收集。如果將該數(shù)值改大，原有的unique sql信息保留，同時(shí)開始收集新的unique sql。如果將該數(shù)值改小，則會(huì)清空當(dāng)前CN節(jié)點(diǎn)所有已收集的unique sql信息，然后開始收集新的unique sql。

設(shè)置好上述變量后，Unique sql統(tǒng)計(jì)視圖可以像普通視圖一樣查詢，例如：

postgres=# select node_name,query,n_calls from pgxc_instr_unique_sql;
  node_name   |                           query                            | n_calls
--------------+------------------------------------------------------------+---------
 coordinator2 | select node_name,query,n_calls from pgxc_instr_unique_sql; |       0
(1 row)

系統(tǒng)函數(shù)reset_instr_unique_sql可以清理unique sql信息，該函數(shù)有3個(gè)參數(shù)，含義如下：

1. scope：如果為"GLOBAL"，則清除所有CN節(jié)點(diǎn)上的數(shù)據(jù)；如果為"LOCAL"，只清空當(dāng)前CN上的數(shù)據(jù)。

2. type：如果為“ALL”，則清除所有數(shù)據(jù)；如果為"BY_USERID"，只清除指定用戶的unique SQL；如果為"BY_CNID"，只清除指定CN的unique SQL。

3. value：如果type=“ALL”，該參數(shù)無意義；如果type="BY_USERID"，該參數(shù)為指定用戶的ID，如果type="BY_CNID"，該參數(shù)為指定CN的ID。

例如：

postgres=# select reset_instr_unique_sql('global','all',0);
 reset_instr_unique_sql
------------------------
 t
(1 row)

此外，如果數(shù)據(jù)庫進(jìn)程重啟，也會(huì)導(dǎo)致之前收集的unique SQL信息被清空。

4、用Unique SQL輔助定位問題

unique sql視圖提供了豐富的信息，用戶可以根據(jù)需要選取對(duì)自己有幫助的信息使用。本節(jié)針對(duì)客戶在生產(chǎn)環(huán)境中遇到的實(shí)際情況，舉例說明幾種該視圖的使用方法，可供性能優(yōu)化參考。

4.1查詢異常的行活動(dòng)導(dǎo)致的磁盤爭用

異常的行活動(dòng)可能引起磁盤爭用，導(dǎo)致業(yè)務(wù)運(yùn)行緩慢。通過查看掃描的行數(shù)、返回的函數(shù)、更改的行數(shù)等指標(biāo)的波動(dòng)情況，可以發(fā)現(xiàn)異常的行活動(dòng)，幫助定位原因。

postgres=# select sum(n_returned_rows) n_returned_rows, sum(n_tuples_fetched) n_tuples_fetched,
    sum(n_tuples_returned) n_tuples_returned, sum(n_tuples_inserted) n_tuples_inserted,
    sum(n_tuples_updated) n_tuples_updated, sum(n_tuples_deleted) n_tuples_deleted from pgxc_instr_unique_sql;
 n_returned_rows | n_tuples_fetched | n_tuples_returned | n_tuples_inserted | n_tuples_updated | n_tuples_deleted
-----------------+------------------+-------------------+-------------------+------------------+------------------
             234 |                0 |                 0 |                 0 |                0 |                0
(1 row)

4.2查詢Top SQL對(duì)資源的占用情況

可以基于執(zhí)行時(shí)間、CPU時(shí)間、掃描行數(shù)、物理讀/邏輯讀等指標(biāo)，對(duì)unique SQL視圖中的SQL語句進(jìn)行排序，找出占用資源最多的那些SQL語句，有針對(duì)性地其分析對(duì)性能的影響和原因，幫助查找和定位問題。例如,

按SQL執(zhí)行時(shí)間順序或倒序排序：

SELECT user_name, unique_sql_id, query, total_elapse_time FROM pgxc_instr_unique_sql ORDER BY total_elapse_time ASC 或 DESC;

按SQL執(zhí)行占用CPU時(shí)間進(jìn)行順序或倒序排序：

SELECT user_name, unique_sql_id, query, cpu_time FROM pgxc_instr_unique_sql ORDER BY cpu_time ASC 或 DESC;

按SQL順序掃描行數(shù)順序或倒序排序：

SELECT user_name, unique_sql_id, query, n_tuples_returned FROM pgxc_instr_unique_sql ORDER BY n_tuples_returned ASC 或 DESC;

按SQL總掃描行進(jìn)行順序或倒序排序：

SELECT user_name, unique_sql_id, query, n_tuples_fetched + n_tuples_returned FROM pgxc_instr_unique_sql ORDER BY n_tuples_fetched + n_tuples_returned ASC 或 DESC;

按SQL執(zhí)行執(zhí)行器時(shí)間進(jìn)行順序或倒序排序：

SELECT user_name, unique_sql_id, query, execution_time FROM pgxc_instr_unique_sql ORDER BY execution_time ASC 或 DESC;

按SQL執(zhí)行物理讀次數(shù)進(jìn)行順序或倒序排序：

SELECT user_name, unique_sql_id, query, n_blocks_fetched FROM pgxc_instr_unique_sql ORDER BY n_blocks_fetched ASC 或 DESC;

按SQL執(zhí)行邏輯讀次數(shù)進(jìn)行順序或倒序排序：

SELECT user_name, unique_sql_id, query, n_blocks_hit FROM pgxc_instr_unique_sql ORDER BY n_blocks_hit ASC 或 DESC;

4.3查詢邏輯讀/物理讀數(shù)量

邏輯讀/物理讀過多可能導(dǎo)致SQL語句占用較多的CPU時(shí)間。通過查詢unique SQL視圖可以得到sql語句邏輯/物理讀數(shù)據(jù)塊的數(shù)量，輔助判斷響應(yīng)過慢的原因：

查詢物理讀塊數(shù)量：

SELECT n_blocks_fetched FROM pgxc_instr_unique_sql;

查詢邏輯讀塊數(shù)量：

SELECT n_blocks_hit FROM pgxc_instr_unique_sql;

4.4診斷內(nèi)存配額不足導(dǎo)致性能低下

如果數(shù)據(jù)庫緩沖區(qū)設(shè)置得太小，會(huì)導(dǎo)致每個(gè)SQL語句執(zhí)行的結(jié)果不能被緩存，當(dāng)前SQL執(zhí)行完畢如果有其他SQL執(zhí)行就會(huì)把內(nèi)存中上一個(gè)或上幾個(gè)SQL緩存的執(zhí)行結(jié)果擠出去，下一輪如果當(dāng)前這個(gè)SQL再次執(zhí)行時(shí)候又需要從磁盤進(jìn)行物理IO讀取數(shù)據(jù)，而不能直接從緩存中獲取數(shù)據(jù)，進(jìn)而導(dǎo)致SQL執(zhí)行性能較差。

緩沖區(qū)配額是否足夠大，可以通過命中率來判斷。緩沖區(qū)命中率=n_blocks_hit/n_blocks_fetched，可以通過查詢unique SQL來診斷是否存在內(nèi)存配額不足的問題：

SELECT (n_blocks_hit/ n_blocks_fetched) AS hit_ratio from pgxc_instr_unique_sql;

以上就是詳解Unique SQL原理和應(yīng)用的詳細(xì)內(nèi)容，更多關(guān)于Unique SQL原理和應(yīng)用的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論