在達夢資料庫中可以透過V$DMSQL_EXEC_TIME和debug方式來定位儲存過程存在的效能問題，但V$DMSQL_EXEC_TIME往往定位比較粗糙，沒法定位到儲存過程中sql的執行時間，而debug可以點位具體某段sql，但如果儲存過程裡面有大量遊標，引數變數值很多的情況下，debug除錯也花費大量時間，下面介紹使用日誌表來排查儲存過程哪些地方耗時較長。
示例如下：儲存過程呼叫需要46分鐘
儲存過程如下：遊標依次獲取表中唯一的fid，將fid值傳入到3個儲存過程呼叫。
CREATE OR REPLACE PROCEDURE "TEST"."P_TEST" as
declare
V_FID TESTA.FID%type;
cursor c_cursor is
select distinct(FID) from TESTA;
begin
open c_cursor;
fetch c_cursor into V_FID;
while c_cursor %found loop
call P_TEST1(V_FID);
call P_TEST2(V_FID);
call P_TEST3(V_FID);
fetch c_cursor into V_FID;
end loop;
close c_cursor;
end;
如下查詢，表中含有211個不同的FID，需要迴圈211次
建立日誌表，根據自己的愛好及實際情況建立欄位
CREATE TABLE dmlog (name1 VARCHAR(20),name2 VARCHAR(20),name3 DATETIME)
建立日誌表之後，將程式每個步驟的前後執行時間寫入到日誌表，如下所示：
重新執行儲存過程，執行完之後檢視日誌表
從上可以看到，基本都是stp2到stp3之間的P_TEST2耗時比較久，儲存過程如下：
單獨查詢需要7s，慢在排序
在t1的A欄位建立降序索引消除排序
CREATE OR REPLACE INDEX "TEST"."IX_T1_A" ON "TEST"."T1"("A" desc)
查詢執行時間減少到2毫秒
在dmlog日誌表裡面看到，有些引數在stp3和stp4之間的P_test3執行也比較慢
p_test3儲存過程如下：
單獨查詢需要9s，慢在全表掃描，
在fid欄位建立索引
CREATE index idx_testa_fid on testa(fid);
索引建立之後執行時間3s，還是比較慢，慢在回表
建立組合索引消除回表，執行時間顯著減少
CREATE or REPLACE index idx_testa_fid on testa(fid,SNo,FAcct,Balance,Available,Income);
最佳化之後，儲存過程執行由46分鐘減少到5分鐘
檢視dmlog日誌，大部分執行都非常快
如下兩個引數在呼叫p_test3時耗時較長
將引數帶入進去查詢，執行計劃正常
原因是該表資料分佈不均衡，當fid為123456，123006時，資料量大導致insert需要比較長的時間
