1. 程式人生 > >如何使用效能分析工具定位SQL執行慢的原因?

如何使用效能分析工具定位SQL執行慢的原因?

但實際上 SQL 執行起來可能還是很慢,那麼到底從哪裡定位 SQL 查詢慢的問題呢?是索引設計的問題?伺服器引數配置的問題?還是需要增加快取的問題呢?效能分析來入手分析,定位導致 SQL 執行慢的原因。

前面已經更新了總結核心的主要三點

  • 如何使用慢查詢日誌查詢執行慢的 SQL 語句?
  • 如何使用 EXPLAIN 檢視 SQL 執行計劃?
  • 如何使用 SHOW PROFILING 分析 SQL 執行步驟中的每一步的執行時間?

那講了這這麼多資料庫伺服器的優化分析的步驟是怎樣的?中間有哪些需要注意的地方?本篇主要是針對這一個話題的總結和概括。

資料庫伺服器的優化步驟

當我們遇到資料庫調優問題的時候,該如何思考呢?我把思考的流程整理成了下面這張圖。

整個流程劃分成了觀察(Show status)和行動(Action)兩個部分。字母 S 的部分代表觀察(會使用相應的分析工具),字母 A 代表的部分是行動(對應分析可以採取的行動)

通過觀察瞭解資料庫整體的執行狀態,通過效能分析工具可以讓我們瞭解執行慢的 SQL 都有哪些,檢視具體的 SQL 執行計劃,甚至是 SQL 執行中的每一步的成本代價,這樣才能定位問題所在,找到了問題,再採取相應的行動

詳細解釋一下這張圖

首先在 S1 部分,我們需要觀察伺服器的狀態是否存在週期性的波動。如果存在週期性波動,有可能是週期性節點的原因,比如雙十一、促銷活動等。這樣的話,我們可以通過 A1 這一步驟解決,也就是加快取,或者更改快取失效策略

如果快取策略沒有解決,或者不是週期性波動的原因,我們就需要進一步分析查詢延遲和卡頓的原因。接下來進入 S2 這一步,我們需要開啟慢查詢。慢查詢可以幫我們定位執行慢的 SQL 語句。我們可以通過設定long_query_time引數定義“慢”的閾值,如果 SQL 執行時間超過了long_query_time,則會認為是慢查詢。當收集上來這些慢查詢之後,我們就可以通過分析工具對慢查詢日誌進行分析

在 S3 這一步驟中,我們就知道了執行慢的 SQL 語句,這樣就可以針對性地用 EXPLAIN 檢視對應 SQL 語句的執行計劃,或者使用 SHOW PROFILE 檢視 SQL 中每一個步驟的時間成本。這樣我們就可以瞭解 SQL 查詢慢是因為執行時間長,還是等待時間長

如果是 SQL 等待時間長,我們進入 A2 步驟。在這一步驟中,我們可以調優伺服器的引數,比如適當增加資料庫緩衝池等。如果是 SQL 執行時間長,就進入 A3 步驟,這一步中我們需要考慮是索引設計的問題?還是查詢關聯的資料表過多?還是因為資料表的欄位設計問題導致了這一現象。然後在這些維度上進行對應的調整

如果 A2 和 A3 都不能解決問題,我們需要考慮資料庫自身的 SQL 查詢效能是否已經達到了瓶頸,如果確認沒有達到效能瓶頸,就需要重新檢查,重複以上的步驟。如果已經達到了效能瓶頸,進入 A4 階段,需要考慮增加伺服器,採用讀寫分離的架構,或者考慮對資料庫分庫分表,比如垂直分庫、垂直分表和水平分表等

以上就是資料庫調優的流程思路。當我們發現執行 SQL 時存在不規則延遲或卡頓的時候,就可以採用分析工具幫我們定位有問題的 SQL,這三種分析工具你可以理解是 SQL 調優的三個步驟:慢查詢、EXPLAIN 和 SHOW PROFILE

總結

結合前面三篇的分步解讀分析

  • 如何使用慢查詢日誌查詢執行慢的 SQL 語句?
  • 如何使用 EXPLAIN 檢視 SQL 執行計劃?
  • 如何使用 SHOW PROFILING 分析 SQL 執行步驟中的每一步的執行時間?
    從步驟上看,我們需要先進行觀察和分析,分析工具的使用在日常工作中還是很重要的。今天只介紹了常用的三種分析工具,實際上可以使用的分析工具還有很多。

這裡總結一下文章裡提到的三種分析工具。我們可以通過慢查詢日誌定位執行慢的 SQL,然後通過 EXPLAIN 分析該 SQL 語句是否使用到了索引,以及具體的資料表訪問方式是怎樣的。我們也可以使用 SHOW PROFILE 進一步瞭解 SQL 每一步的執行時間,包括 I/O 和 CPU 等資源的使用情況