但實際上 sql 執行起來可能還是很慢，那麼到底從**定位 sql 查詢慢的問題呢？是索引設計的問題？伺服器引數配置的問題？還是需要增加快取的問題呢？效能分析來入手分析，定位導致 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 profile 進一步了解 sql 每一步的執行時間，包括 i/o 和 cpu 等資源的使用情況
linux下使用效能分析工具nmon
一 簡介 nmon 工具可以幫助在乙個螢幕上顯示所有重要的效能優化資訊，並動態地對其進行更新。這個高效的工具可以工作於任何啞螢幕 telnet 會話 甚至撥號線路。另外，它並不會消耗大量的 cpu 週期，通常低於百分之二。在更新的計算機上，其 cpu 使用率將低於百分之一。使用啞螢幕，在螢幕上對資料...
使用TraceView工具定位耗時操作
eclipse中生成trace檔案的方法 android studio生成trace檔案的方法 生成的trace檔案將顯示在captures視窗 直接把trace檔案拖到安裝了adt外掛程式的eclipse就能開啟。timeline展示各個執行緒占用cpu的情況。橫軸為從開始到結束trace的cpu...
效能測試 瓶頸定位 工具使用（下）
報告分析 1 為方便查詢 a 以 timestamp webtestname userload 命名 test result b 將部分指標以 換算 ex network i o fail ratio 2 效能定位的目的 基於成本考量，將系統最昂貴部分用至極限從而確定了優先順序排序 i o cpu ...