生產環境sql語句調優實戰第四篇
生產中有一條sql語句消耗了大量的cpu資源，執行時間在18秒左右，
sql語句如下，略微做了刪改。
select t_run_request.run_mode,
t_cycle_groups.flow_id,
t_cycle_groups.request_id,
t_cycle_groups.dynamic_attributes,
t_cycle_groups.sys_creation_date,
t_cycle_groups.sys_update_date,
t_cycle_control.cycle_code
from (select t_cycle_groups.*, a.request_id
from (select t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id
from t_cycle_groups, --8000多條資料
t_group_status --100多萬條資料
where t_cycle_groups.group_id = t_group_status.group_id
AND t_cycle_groups.flow_id = t_group_status.flow_id
AND t_cycle_groups.cycle_seq_no =
t_group_status.cycle_seq_no
AND t_cycle_groups.route = t_group_status.route
group by t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id) a,
t_cycle_groups
where t_cycle_groups.group_id = a.group_id
AND t_cycle_groups.flow_id = a.flow_id
AND t_cycle_groups.cycle_seq_no = a.cycle_seq_no
AND t_cycle_groups.route = a.route) t_cycle_groups,
t_cycle_control, --2121多條資料
t_run_request --6000多條資料
where t_cycle_groups.status = 'FIN'
AND t_cycle_groups.request_id = t_run_request.request_id
AND t_cycle_control.cycle_seq_no = t_cycle_groups.cycle_seq_no
AND (t_run_request.population_type = 'CYC' OR
t_run_request.population_type = 'CCD')
AND t_run_request.population_id = t_cycle_control.cycle_seq_no
order by t_cycle_groups.request_id
|
Session |
: |
PRODBUSER (1560:61133) |
|
SQL ID |
: |
1hg2wcuapy3y3 |
|
SQL Execution ID |
: |
16871963 |
|
Execution Started |
: |
07/21/2014 12:30:20 |
|
First Refresh Time |
: |
07/21/2014 12:30:24 |
|
Last Refresh Time |
: |
07/21/2014 12:30:37 |
|
Duration |
: |
18s |
|
Module/Action |
: |
JDBC Thin Client/- |
|
Service |
: |
PRODB |
|
Program |
: |
JDBC Thin Client |
|
Fetch Calls |
: |
771 |
sql語句如下，略微做了刪改。
select t_run_request.run_mode,
t_cycle_groups.flow_id,
t_cycle_groups.request_id,
t_cycle_groups.dynamic_attributes,
t_cycle_groups.sys_creation_date,
t_cycle_groups.sys_update_date,
t_cycle_control.cycle_code
from (select t_cycle_groups.*, a.request_id
from (select t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id
from t_cycle_groups, --8000多條資料
t_group_status --100多萬條資料
where t_cycle_groups.group_id = t_group_status.group_id
AND t_cycle_groups.flow_id = t_group_status.flow_id
AND t_cycle_groups.cycle_seq_no =
t_group_status.cycle_seq_no
AND t_cycle_groups.route = t_group_status.route
group by t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id) a,
t_cycle_groups
where t_cycle_groups.group_id = a.group_id
AND t_cycle_groups.flow_id = a.flow_id
AND t_cycle_groups.cycle_seq_no = a.cycle_seq_no
AND t_cycle_groups.route = a.route) t_cycle_groups,
t_cycle_control, --2121多條資料
t_run_request --6000多條資料
where t_cycle_groups.status = 'FIN'
AND t_cycle_groups.request_id = t_run_request.request_id
AND t_cycle_control.cycle_seq_no = t_cycle_groups.cycle_seq_no
AND (t_run_request.population_type = 'CYC' OR
t_run_request.population_type = 'CCD')
AND t_run_request.population_id = t_cycle_control.cycle_seq_no
order by t_cycle_groups.request_id
執行計劃如下：
Plan hash value: 2458454793
------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4271K| 822M| | 201K (1)| 00:40:23 | | |
| 1 | SORT ORDER BY | | 4271K| 822M| 855M| 201K (1)| 00:40:23 | | |
|* 2 | HASH JOIN | | 4271K| 822M| | 13779 (1)| 00:02:46 | | |
| 3 | VIEW | VW_NSO_1 | 423 | 13959 | | 27 (8)| 00:00:01 | | |
| 4 | HASH UNIQUE | | 423 | 12690 | | 27 (8)| 00:00:01 | | |
|* 5 | HASH JOIN | | 5876 | 172K| | 26 (4)| 00:00:01 | | |
| 6 | VIEW | index$_join$_009 | 2119 | 16952 | | 3 (34)| 00:00:01 | | |
|* 7 | HASH JOIN | | | | | | | | |
| 8 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_PK | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
| 9 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_1IX | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
|* 10 | TABLE ACCESS FULL | T_RUN_REQUEST | 6038 | 129K| | 23 (0)| 00:00:01 | | |
|* 11 | HASH JOIN | | 1009K| 162M| | 13735 (1)| 00:02:45 | | |
| 12 | TABLE ACCESS FULL | T_RUN_REQUEST | 6110 | 67210 | | 23 (0)| 00:00:01 | | |
|* 13 | HASH JOIN | | 1009K| 152M| | 13708 (1)| 00:02:45 | | |
| 14 | JOIN FILTER CREATE | :BF0000 | 8824 | 1128K| | 48 (3)| 00:00:01 | | |
|* 15 | HASH JOIN | | 8824 | 1128K| | 48 (3)| 00:00:01 | | |
| 16 | VIEW | index$_join$_006 | 2119 | 16952 | | 3 (34)| 00:00:01 | | |
|* 17 | HASH JOIN | | | | | | | | |
| 18 | INDEX FAST FULL SCAN| T_CYCLE_CONTROL_PK | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
| 19 | INDEX FAST FULL SCAN| T_CYCLE_CONTROL_1IX | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
|* 20 | TABLE ACCESS FULL | T_CYCLE_GROUPS | 8862 | 1064K| | 45 (0)| 00:00:01 | | |
| 21 | VIEW | | 1014K| 26M| | 13656 (1)| 00:02:44 | | |
| 22 | HASH GROUP BY | | 1014K| 48M| 62M| 13656 (1)| 00:02:44 | | |
| 23 | JOIN FILTER USE | :BF0000 | 1014K| 48M| | 1170 (1)| 00:00:15 | | |
| 24 | NESTED LOOPS | | 1014K| 48M| | 1170 (1)| 00:00:15 | | |
| 25 | PARTITION RANGE ALL | | 1014K| 26M| | 1165 (0)| 00:00:14 | 1 | 19 |
| 26 | INDEX FULL SCAN | T_GROUP_STATUS_PK | 1014K| 26M| | 1165 (0)| 00:00:14 | 1 | 19 |
|* 27 | INDEX UNIQUE SCAN | T_CYCLE_GROUPS_PK | 1 | 23 | | 1 (0)| 00:00:01 | | |
------------------------------------------------------------------------------------------------------------------------------
可以看到，執行計劃裡面的預估，資源消耗是很嚴重的的，幸好涉及的幾個表資料量都不算大。
根據資料量和執行計劃可以得到。執行計劃和實際的執行情況有很大的差別。實際執行時，返回的最終資料量只有9000多條，但是根據執行計劃卻有400多萬。
其實問題可以歸結為下面的一個子查詢。
子查詢中，因為t_cycle_groups含有clob欄位且要作為最終的輸出，clob欄位不能做order by/group by的操作。所以開發最開始就先根據主鍵的情況和t_group_status來做關聯(t_group_status中有100多萬條資料),同時匹配t_group_status中的一個欄位，過濾掉多餘的資料記錄，然後在子查詢外再和表t_group_status做關聯輸出clob欄位。
下面的例子中，子查詢的別名為a,在子查詢中根據主鍵和大表做關聯，輸出了小表的所有主鍵列和大表的一個列。大表的這個列和小表的主鍵列匹配會有很多冗餘資料，需要做group by，在外層又重新和t_cycle_groups做關聯。
這個操作可以打個比方，比如我有一張信用卡，在這個月的10,11,12,14號每天都刷了3次卡，現在就是想輸出我在哪些天刷了卡，只需要輸出10,11,12,14就可以，不需要輸出每次刷卡的具體時間。
select t_cycle_groups.*, a.request_id
from (select t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id
from t_cycle_groups, --8000多條資料
t_group_status --100多萬條資料
where t_cycle_groups.group_id = t_group_status.group_id
AND t_cycle_groups.flow_id = t_group_status.flow_id
AND t_cycle_groups.cycle_seq_no =
t_group_status.cycle_seq_no
AND t_cycle_groups.route = t_group_status.route
group by t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id) a,
t_cycle_groups
where t_cycle_groups.group_id = a.group_id
AND t_cycle_groups.flow_id = a.flow_id
AND t_cycle_groups.cycle_seq_no = a.cycle_seq_no
AND t_cycle_groups.route = a.route
最佳化後的子查詢如下：
因為主鍵列是固定的，我直接使用rowid來替代。這樣過group by的時候會減少很多的資料過濾，在子查詢過濾了最多的資料之後才和表重新關聯，最後輸出clob欄位。
這樣就避免了反覆比較主鍵列，過多複雜的資料group by。
select T_cycle_groups.flow_id,
temp.request_id,
T_cycle_groups.dynamic_attributes,
T_cycle_groups.sys_creation_date,
T_cycle_groups.sys_update_date,
T_cycle_groups.cycle_seq_no
from (select T_cycle_groups.rowid temp_id,
T_group_status.request_id
from T_cycle_groups, T_group_status
where T_cycle_groups.group_id = T_group_status.group_id
AND T_cycle_groups.flow_id = T_group_status.flow_id
AND T_cycle_groups.cycle_seq_no =
T_group_status.cycle_seq_no
AND T_cycle_groups.route = T_group_status.route
group by T_cycle_groups.rowid, T_group_status.request_id) temp,
T_cycle_groups
where temp.temp_id = T_cycle_groups.rowid
and T_cycle_groups.status = 'FIN'
改進後再次查詢，整個查詢的效能就好多了，從執行計劃來說，資源的消耗就比較合理了。
--------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 332 | 1277 (4)| 00:00:16 | | |
| 1 | SORT ORDER BY | | 2 | 332 | 1277 (4)| 00:00:16 | | |
|* 2 | HASH JOIN | | 2 | 332 | 1276 (4)| 00:00:16 | | |
|* 3 | TABLE ACCESS FULL | T_RUN_REQUEST | 6038 | 112K| 23 (0)| 00:00:01 | | |
|* 4 | HASH JOIN | | 3224 | 462K| 1253 (4)| 00:00:16 | | |
| 5 | VIEW | index$_join$_006 | 2119 | 16952 | 3 (34)| 00:00:01 | | |
|* 6 | HASH JOIN | | | | | | | |
| 7 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_PK | 2119 | 16952 | 1 (0)| 00:00:01 | | |
| 8 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_1IX | 2119 | 16952 | 1 (0)| 00:00:01 | | |
|* 9 | HASH JOIN | | 3238 | 439K| 1249 (4)| 00:00:15 | | |
| 10 | VIEW | | 3252 | 52032 | 1204 (4)| 00:00:15 | | |
| 11 | HASH GROUP BY | | 3252 | 196K| 1204 (4)| 00:00:15 | | |
| 12 | NESTED LOOPS | | 1014K| 59M| 1170 (1)| 00:00:15 | | |
| 13 | PARTITION RANGE ALL| | 1014K| 26M| 1165 (0)| 00:00:14 | 1 | 19 |
| 14 | INDEX FULL SCAN | T_GROUP_STATUS_PK | 1014K| 26M| 1165 (0)| 00:00:14 | 1 | 19 |
|* 15 | INDEX UNIQUE SCAN | T_CYCLE_GROUPS_PK | 1 | 35 | 1 (0)| 00:00:01 | | |
|* 16 | TABLE ACCESS FULL | T_CYCLE_GROUPS | 8862 | 1064K| 45 (0)| 00:00:01 | | |
--------------------------------------------------------------------------------------------------------------------
查詢的執行時間也保持在5秒左右。
Plan hash value: 2458454793
------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 4271K| 822M| | 201K (1)| 00:40:23 | | |
| 1 | SORT ORDER BY | | 4271K| 822M| 855M| 201K (1)| 00:40:23 | | |
|* 2 | HASH JOIN | | 4271K| 822M| | 13779 (1)| 00:02:46 | | |
| 3 | VIEW | VW_NSO_1 | 423 | 13959 | | 27 (8)| 00:00:01 | | |
| 4 | HASH UNIQUE | | 423 | 12690 | | 27 (8)| 00:00:01 | | |
|* 5 | HASH JOIN | | 5876 | 172K| | 26 (4)| 00:00:01 | | |
| 6 | VIEW | index$_join$_009 | 2119 | 16952 | | 3 (34)| 00:00:01 | | |
|* 7 | HASH JOIN | | | | | | | | |
| 8 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_PK | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
| 9 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_1IX | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
|* 10 | TABLE ACCESS FULL | T_RUN_REQUEST | 6038 | 129K| | 23 (0)| 00:00:01 | | |
|* 11 | HASH JOIN | | 1009K| 162M| | 13735 (1)| 00:02:45 | | |
| 12 | TABLE ACCESS FULL | T_RUN_REQUEST | 6110 | 67210 | | 23 (0)| 00:00:01 | | |
|* 13 | HASH JOIN | | 1009K| 152M| | 13708 (1)| 00:02:45 | | |
| 14 | JOIN FILTER CREATE | :BF0000 | 8824 | 1128K| | 48 (3)| 00:00:01 | | |
|* 15 | HASH JOIN | | 8824 | 1128K| | 48 (3)| 00:00:01 | | |
| 16 | VIEW | index$_join$_006 | 2119 | 16952 | | 3 (34)| 00:00:01 | | |
|* 17 | HASH JOIN | | | | | | | | |
| 18 | INDEX FAST FULL SCAN| T_CYCLE_CONTROL_PK | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
| 19 | INDEX FAST FULL SCAN| T_CYCLE_CONTROL_1IX | 2119 | 16952 | | 1 (0)| 00:00:01 | | |
|* 20 | TABLE ACCESS FULL | T_CYCLE_GROUPS | 8862 | 1064K| | 45 (0)| 00:00:01 | | |
| 21 | VIEW | | 1014K| 26M| | 13656 (1)| 00:02:44 | | |
| 22 | HASH GROUP BY | | 1014K| 48M| 62M| 13656 (1)| 00:02:44 | | |
| 23 | JOIN FILTER USE | :BF0000 | 1014K| 48M| | 1170 (1)| 00:00:15 | | |
| 24 | NESTED LOOPS | | 1014K| 48M| | 1170 (1)| 00:00:15 | | |
| 25 | PARTITION RANGE ALL | | 1014K| 26M| | 1165 (0)| 00:00:14 | 1 | 19 |
| 26 | INDEX FULL SCAN | T_GROUP_STATUS_PK | 1014K| 26M| | 1165 (0)| 00:00:14 | 1 | 19 |
|* 27 | INDEX UNIQUE SCAN | T_CYCLE_GROUPS_PK | 1 | 23 | | 1 (0)| 00:00:01 | | |
------------------------------------------------------------------------------------------------------------------------------
可以看到，執行計劃裡面的預估，資源消耗是很嚴重的的，幸好涉及的幾個表資料量都不算大。
根據資料量和執行計劃可以得到。執行計劃和實際的執行情況有很大的差別。實際執行時，返回的最終資料量只有9000多條，但是根據執行計劃卻有400多萬。
其實問題可以歸結為下面的一個子查詢。
子查詢中，因為t_cycle_groups含有clob欄位且要作為最終的輸出，clob欄位不能做order by/group by的操作。所以開發最開始就先根據主鍵的情況和t_group_status來做關聯(t_group_status中有100多萬條資料),同時匹配t_group_status中的一個欄位，過濾掉多餘的資料記錄，然後在子查詢外再和表t_group_status做關聯輸出clob欄位。
下面的例子中，子查詢的別名為a,在子查詢中根據主鍵和大表做關聯，輸出了小表的所有主鍵列和大表的一個列。大表的這個列和小表的主鍵列匹配會有很多冗餘資料，需要做group by，在外層又重新和t_cycle_groups做關聯。
這個操作可以打個比方，比如我有一張信用卡，在這個月的10,11,12,14號每天都刷了3次卡，現在就是想輸出我在哪些天刷了卡，只需要輸出10,11,12,14就可以，不需要輸出每次刷卡的具體時間。
select t_cycle_groups.*, a.request_id
from (select t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id
from t_cycle_groups, --8000多條資料
t_group_status --100多萬條資料
where t_cycle_groups.group_id = t_group_status.group_id
AND t_cycle_groups.flow_id = t_group_status.flow_id
AND t_cycle_groups.cycle_seq_no =
t_group_status.cycle_seq_no
AND t_cycle_groups.route = t_group_status.route
group by t_cycle_groups.group_id,
t_cycle_groups.flow_id,
t_cycle_groups.cycle_seq_no,
t_cycle_groups.route,
t_group_status.request_id) a,
t_cycle_groups
where t_cycle_groups.group_id = a.group_id
AND t_cycle_groups.flow_id = a.flow_id
AND t_cycle_groups.cycle_seq_no = a.cycle_seq_no
AND t_cycle_groups.route = a.route
最佳化後的子查詢如下：
因為主鍵列是固定的，我直接使用rowid來替代。這樣過group by的時候會減少很多的資料過濾，在子查詢過濾了最多的資料之後才和表重新關聯，最後輸出clob欄位。
這樣就避免了反覆比較主鍵列，過多複雜的資料group by。
select T_cycle_groups.flow_id,
temp.request_id,
T_cycle_groups.dynamic_attributes,
T_cycle_groups.sys_creation_date,
T_cycle_groups.sys_update_date,
T_cycle_groups.cycle_seq_no
from (select T_cycle_groups.rowid temp_id,
T_group_status.request_id
from T_cycle_groups, T_group_status
where T_cycle_groups.group_id = T_group_status.group_id
AND T_cycle_groups.flow_id = T_group_status.flow_id
AND T_cycle_groups.cycle_seq_no =
T_group_status.cycle_seq_no
AND T_cycle_groups.route = T_group_status.route
group by T_cycle_groups.rowid, T_group_status.request_id) temp,
T_cycle_groups
where temp.temp_id = T_cycle_groups.rowid
and T_cycle_groups.status = 'FIN'
改進後再次查詢，整個查詢的效能就好多了，從執行計劃來說，資源的消耗就比較合理了。
--------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 332 | 1277 (4)| 00:00:16 | | |
| 1 | SORT ORDER BY | | 2 | 332 | 1277 (4)| 00:00:16 | | |
|* 2 | HASH JOIN | | 2 | 332 | 1276 (4)| 00:00:16 | | |
|* 3 | TABLE ACCESS FULL | T_RUN_REQUEST | 6038 | 112K| 23 (0)| 00:00:01 | | |
|* 4 | HASH JOIN | | 3224 | 462K| 1253 (4)| 00:00:16 | | |
| 5 | VIEW | index$_join$_006 | 2119 | 16952 | 3 (34)| 00:00:01 | | |
|* 6 | HASH JOIN | | | | | | | |
| 7 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_PK | 2119 | 16952 | 1 (0)| 00:00:01 | | |
| 8 | INDEX FAST FULL SCAN | T_CYCLE_CONTROL_1IX | 2119 | 16952 | 1 (0)| 00:00:01 | | |
|* 9 | HASH JOIN | | 3238 | 439K| 1249 (4)| 00:00:15 | | |
| 10 | VIEW | | 3252 | 52032 | 1204 (4)| 00:00:15 | | |
| 11 | HASH GROUP BY | | 3252 | 196K| 1204 (4)| 00:00:15 | | |
| 12 | NESTED LOOPS | | 1014K| 59M| 1170 (1)| 00:00:15 | | |
| 13 | PARTITION RANGE ALL| | 1014K| 26M| 1165 (0)| 00:00:14 | 1 | 19 |
| 14 | INDEX FULL SCAN | T_GROUP_STATUS_PK | 1014K| 26M| 1165 (0)| 00:00:14 | 1 | 19 |
|* 15 | INDEX UNIQUE SCAN | T_CYCLE_GROUPS_PK | 1 | 35 | 1 (0)| 00:00:01 | | |
|* 16 | TABLE ACCESS FULL | T_CYCLE_GROUPS | 8862 | 1064K| 45 (0)| 00:00:01 | | |
--------------------------------------------------------------------------------------------------------------------
查詢的執行時間也保持在5秒左右。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8494287/viewspace-1347086/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 生產環境sql語句調優實戰第二篇SQL
- 生產環境sql語句調優實戰第三篇SQL
- 生產環境sql語句調優實戰第五篇SQL
- 生產環境sql語句調優實戰第六篇SQL
- 生產環境sql語句調優實戰第八篇SQL
- 生產環境sql語句調優實戰第九篇SQL
- 生產環境sql語句調優實戰第七篇SQL
- 生產環境sql語句調優實戰第十篇SQL
- 生產環境大型sql語句調優實戰第一篇（一）SQL
- 生產環境大型sql語句調優實戰第一篇（二）SQL
- kafka生產環境規劃-kafka 商業環境實戰Kafka
- 使用hint來調優sql語句SQL
- 實戰生產環境vCenter HA配置（VCSA6.5）
- kafka生產者Producer引數設定及引數調優建議-kafka 商業環境實戰Kafka
- Eureka：生產環境優化總結。優化
- 生產系統pl/sql調優案例SQL
- MySQL調優篇 | SQL調優實戰（5）MySql
- oracle 對比sql語句執行環境OracleSQL
- SQL 語句調優_減少或者避免笛卡爾乘積的發生SQL
- 生產sql調優之統計資訊分析SQL
- 透過使用hint unnest調優sql語句SQL
- 通過使用hint unnest調優sql語句SQL
- 生產SQL語句突然變慢問題定位SQL
- 一條sql語句的建議調優分析SQL
- redmine生產環境搭建
- Django生產環境搭建Django
- SQL語句優化SQL優化
- 使用USE_HASH Hint調優一個SQL語句SQL
- 使用SQL調整顧問進行語句優化SQL優化
- HBase 核心元件協調及RegionServer JVM引數調優-OLAP商業環境實戰元件ServerJVM
- Vue 移動端專案生產環境的優化Vue優化
- Java生產環境效能監控與調優—基於JDK命令列工具的監控JavaJDK命令列
- MYSQL SQL語句優化MySql優化
- sql語句效能優化SQL優化
- SQL語句的優化SQL優化
- 求助：SQL語句優化SQL優化
- SQL Server優化之SQL語句優化SQLServer優化
- soar-PHP - SQL 語句優化器和重寫器的 PHP 擴充套件包、 方便框架中 SQL 語句調優PHPSQL優化套件框架