PMM Query Analytics的查詢分析器怎麼用？典型教學例子一個

網上都是PMM Percona Monitoring and Management的安裝部署文章，今天我出一個使用PMM的教學文章，尋找資料庫負載最高的語句例子。

一、 問題 PMM Query Analytics 的查詢分析器使用方法

二、下面用一個例子來介紹查詢分析器的使用方法，介紹各個引數的意思。先上圖

 

這個圖意思是：我選擇了 2 天取樣時間，對 load 進行排序，選擇一條 sql 語句，這條 sql 語句每秒執行 3.41 次， 2 天時間裡總共執行了 589970 次， sql 負載佔整個 sql 的負載是 80% 。這個是很高很高的了。

如上圖，我選擇了 sql 語句

select member0_.id as id2_166_, member0_.createdDate as createdD3_166_, member0_.lastModifiedDate as lastModi4_166_, member0_.version as version5_166_, member0_.isEnabled as isEnable6_166_, member0_.isLocked as isLocked7_166_, member0_.lastLoginDate as lastLogi8_166_, member0_.lastLoginIp as lastLogi9_166_, member0_.lockDate as lockDat10_166_, member0_.mobile as mobile11_166_, member0_.operatorNo as operato12_166_, member0_.address as address57_166_, member0_.amount as amount58_166_, member0_.area_id as area_id67_166_, member0_.attributeValue0 as attribu18_166_, member0_.attributeValue1 as attribu19_166_, member0_.attributeValue2 as attribu30_166_, member0_.attributeValue3 as attribu31_166_, member0_.attributeValue4 as attribu32_166_, member0_.attributeValue5 as attribu33_166_, member0_.attributeValue6 as attribu34_166_, member0_.attributeValue7 as attribu35_166_, member0_.attributeValue8 as attribu36_166_, member0_.attributeValue9 as attribu37_166_, member0_.balance as balance38_166_, member0_.birth as birth59_166_, member0_.commissionBalance as commiss60_166_, member0_.email as email14_166_, member0_.encodedPassword as encoded15_166_, member0_.frozenAmount as frozenA42_166_, member0_.frozenCommissionBalance as frozenC61_166_, member0_.gender as gender62_166_, member0_.headimgurl as headimg63_166_, member0_.memberRank_id as memberR68_166_, member0_.name as name16_166_, member0_.nickname as nicknam64_166_, member0_.phone as phone52_166_, member0_.point as point65_166_, member0_.safeKeyExpire as safeKey53_166_, member0_.safeKeyValue as safeKey54_166_, member0_.username as usernam17_166_, member0_.zipCode as zipCode66_166_ from Users member0_ where member0_.dtype= ？  and member0_.operatorNo= ？ 得到了下面表格的一些計算資料：

三、 名稱解釋

query time ： 這裡的 query time 和 mysql 的慢日誌裡面query time 兩個概念是一樣的嗎？ 答案是：2個概念是不一樣的。這個是什麼意思呢？這個 query time , 是這條語句總共執行了 9 days,11:25:15 這麼長時間，總共執行了 589.97k 次，得到的平均執行時間是 817200/589970=1.39 sec 。這裡有個奇怪的問題是，我取樣的時間是 2days, 仔細看圖，為什麼這條語句執行時間是 9 天又 11 個小時呢？這裡埋個問題。

Load ：這裡的 load 我沒有真正看出來了含義，表示 sql 執行時間的負載。這裡要注意 sql 負載佔比百分比才有意義。這條 sql 語句佔比 80% ，說明資料庫大部分時間用於執行這條語句。

Query count ：執行次數，本條語句執行 589970 次， qps 是 3.41

Rows examined ：每次執行掃描的行數 473170, 為了執行這條語句，資料庫每次需要掃描 473170 條記錄才能得到這一條記錄，哎呀，好累呀，計算機幹活還是很賣力的，每次執行這條語句都要查詢這麼多記錄。

 

 

query time 是這條語句的平均執行時間，慢日誌查詢的 query time 是本條語句當前執行時間。

發現這條語句有問題後，我去慢查詢日誌看， 慢查詢日誌有2G大，找到了慢日誌sql：

 

四、現在開始最佳化這條語句。

看下現在執行計劃：

 

這條語句用到了索引 key, 不過仍然很慢，執行時間需要 3 秒。檢索了 40401 條記錄。

看下這個表建立了哪些索引？

 

果然有 UKt3bl114953i5jey88j9rk472n 這個索引。

那為什麼還是這麼慢呢？這裡思考 2 分鐘接著往下看：

因為這個索引 (`dtype`,`username`) 能檢索到的資料量還是比較大的，不夠高效，用了這個索引還要檢索40401條記錄。那現在建立一個更加高效的索引：

create index  idx_users_operatorno_2 on users(operatorNo,dtype);

這個時候你再來看執行計劃：

 

看到沒有，使用了我新建立的索引，檢索資料變成 1 條，這樣，再執行一下這條語句，就是 0.01 秒。好了問題解決。

 

四、 剛剛說的 PMM 的 query time 和慢查詢的 query time 計算方法不一樣，假如，如果，我需要方便的從 PMM 的介面得到 sql 語句一次查詢的 query time，該怎麼操作 呢？

答案：縮短取樣時間。

五、

總結：用 PMM 查詢分析，用 load 排序，可以找到負載最大的 sql ，最佳化這個 sql ，整個資料庫的負載就下來了。為什麼呀？其實你可以思考下，資料庫是什麼？可以這樣理解：就是一個不停執行 sql 語句然後返回結果給使用者的機器嘛，沒有了慢查詢 sql ，資料庫負載降低，吞吐量就會提高，表現就會快嘛。