SQL調優的思路是什么

本篇內容介紹了“SQL調優的思路是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一般來說，需要關注下面四種Top SQL

• 消耗最多CPU的(邏輯IO過多)

• 導致過多物理I/O的

• 執行次數較頻繁的

• 執行時間較長的

我們知道，一個語句的響應時間有個很著名的公式：
響應時間=服務時間+等待時間
其中服務時間就是CPU為執行該語句花費的時間。
服務時間=分析時間+遞歸時間+執行時間
分析時間是CPU用于分析語句的時間，遞歸時間是CPU用于語句的遞歸SQL的時間，剩下的則就是CPU用于執行語句的真正時間了。
那么，上面的這些時間信息從哪里來的?Oracle提供的系統統計信息中就有部分的時間統計信息：

• 服務時間=CPU used by this session

• 分析時間=parse time cpu

• 遞歸時間=recursive cpu usage

那么，執行時間就可以根據上面三個統計信息計算得出：
執行時間=CPU used by this session – parse time cpu – recursive cpu usage

• 如果執行時間在整個響應時間中占較大的比例，那么下一步就是找出那些造成了最多邏輯IO的SQL語句，可以從statspack報告的SQL ordered by Gets部分找到。

• 如果分析時間在整個響應時間中占較大的比例，那么下一步就是查找哪些SQL分析過多，這在statspack報告中在SQL ordered by Parse Calls中列出。

• 如果等待時間在整個響應時間中占較大的比例，并且主要是塊讀取相關的等待時，下一步就是找出哪些SQL造成了過多的物理讀，可以查看statspack報告中的SQL ordered by Reads部分。

那么，根據上面列出的一個簡單的原則，我們需要關注三個關于CPU時間的統計信息: CPU used by this session, parse time cpu和recursive cpu usage，以及top5等待事件中和IO相關的等待時間。如果是其他的一些等待事件出現在Top5中，那么可能需要根據不同的等待事件來分析原因了。然后優先調優時間消耗最多的相關SQL。
除了上面的SQL ordered by Gets(邏輯IO最多)，SQL ordered by Parse Calls(軟解析過多)，SQL ordered by Reads(物理IO過多)，statspack還按照其他的一些方式列出了Top SQL，這些Top SQL在某些情況下都是需要給予特別關注的。比如：
　　SQL ordered by Executions 執行次數超過100的
　　SQL ordered by Sharable Memory 占用library cache超過1M的
　　SQL ordered by Version Count 子cursor超過20的
如果沒有statspack，那么根據v$sysstat/v$sesstat中的統計信息，結合v$sql/v$sqlarea，一樣可以得到相關的SQL。
v$sql對于每一個子cursor都有一行統計記錄，而v$sqlarea則對同一個父cursor只有一行統計記錄，也就是v$sqlarea是對v$sql按照父cursor進行group by后的一個結果。這兩個視圖中都有諸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列，和報告列出Top SQL的條件對應。

“SQL調優的思路是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！