本文根據DBAplus社群〖2018年1月6日北京開源與架構技術沙龍〗現場演講內容整理而成。

講師介紹

李季鵬

新炬網路資料庫專家

專注於MySQL資料庫效能管理及相關解決方案，目前主要從事MySQL效能分析工具的設計與研發工作。

目前我從事的是MySQL的技術研究並讓其實現產品化的工作，所以給大家今天分享的是MySQL效能分析的一些思路。

分享大綱：

1.MySQL效能管理需求與現狀

2.MySQL效能分析建設

MySQL效能管理需求與現狀

1、資料庫管理的現實需求

MySQL效能管理的現實需求很直觀，我們現在大部分的客戶都是在傳統企業，而傳統企業這幾年向MySQL轉型也是非常迅猛的。

所以用傳統的商用資料庫建設MySQL時就會發生一些很頭疼的問題，比如：如何讓少量的DBA管理大量的資料庫？如何通過簡單的方式改善和優化資料庫效能問題？如何持續保障資料庫的連續性和穩定性？…

一個極大的風險點在於MySQL的效能資料難鋪展開回溯。MySQL效能資料的特點是比較依賴實時分析或執行分析，事後能得到的資訊較少，也很難下鑽下去。當少量DBA管理大量資料庫時，出現問題只能通過高可用手段快速處理保障可用。但缺乏充足資訊的回溯手段，往往只能在執行時間，鎖定時間等少數幾個維度分析問題SQL的影響程度，其覆蓋面難以包括大部分SQL語句的影響層面，這在很多運維環境上看來，缺乏事後分析手段，都是存在極大風險的。

在這個方面我們需要基於MySQL目前已有的分析手段去做改進，讓MySQL具備它原本不具備的效能資訊增量記錄的能力，並在這個基礎上實現關聯與下鑽分析，便於快速定位到資料庫效能問題。

2.傳統MySQL效能管理手段的限制

從傳統上來說，MySQL效能分析的特點是實時執行、分析手段多樣，事後分析主要依賴Slow日誌。

人工做問題分析，一般需要藉助PT工具(Percona Toolkit)生成時段內慢語句報告，它能得到一些時段內的慢語句情況。但這並不能把PT工具生成報告跟原本在某一時段內的資料庫效能的整體狀態做一個關聯。

假設出現了一個性能問題引起的資料庫宕機故障，因為儲存在資料庫內的狀態資訊P_S資訊在重啟後都丟失了，那我們可以藉助的手段只有日誌分析和監控平臺的狀態指標分析。事實上這是一個比較頭痛的過程，因為這些分析難以關聯、精確定位到造成問題的原因。

另一方面，如果要將這些多樣化的分析手段都產品化，那對我們來說一定是一個穩定性、可用性非常差的選擇。

因此，從簡單即運維這個觀點出發，站在產品化的角度面對不同的使用者時，要儘量減少現場為了適應產品接入而進行的變更，同時還要能夠提供最關鍵的關聯與下鑽分析功能。上述提到的這些點都是我們做設計的過程中一致考慮的問題。

3、優化MySQL效能管理的思考

誰都希望實現的工具是輕量化的，不需要做太多改造就可以接入。效能管理的需求分析起來可歸結為三點：

第一是輕量化採集，即接入資料庫並拿到資料庫效能資訊。常規的分析手段都是用一種形式，但其實用非侵入手段會更好。什麼叫非侵入手段？就是直接給工具提供一個賬號和相應的許可權，然後工具就能通過接入資料庫採集響應的資訊來避免Agent，這樣就能儘量避免自動化採集過程中對目標端的效能影響和風險。

第二是增量化記錄：狀態增標、語句資訊實現增量化記錄，使效能管理具備豐富的時段展示手段和歷史回溯手段。

第三是經驗沉澱：沉澱MySQL效能分析經驗的重點在於沉澱指標關聯，下鑽到問題語句分析過程。整個分析過程很簡單，重點在於提供給使用者在使用層面中哪些指標是需要關聯的、哪些指標是可以幫助我們進一步下鑽的，這樣就可以把分析的邏輯清晰化，也可以解決很多問題。

MySQL效能分析建設

下圖是在MySQL做效能分析裡要去關聯下鑽的總體思路。從圖中可以看出，展示層就是效能入口。我們應該選取少量小而簡單的效能指標來作為它的問題點上浮。

後面是通過效能上浮的指標來提供一系列對比的手段進行分解，同時還能做到指標間的對比、指標和語句的關聯。最後根據突出的效能指標下鑽到語句，並確認語句的執行形態是否造成了效能的風險。

能做到這層指標關聯與下鑽，主要在於資料庫中對語句執行效能資訊的豐富程度遠遠大於日誌記錄的資訊，再將語句執行記錄的資訊與資料庫相關的狀態資訊進行關聯，這樣就更容易分析到語句執行對效能的影響了。

1、效能入口

（1）選取適當的上浮核心指標

如何選取上浮的核心指標，其實質是怎樣去評估一套資料庫的總體效能，這裡主要包括兩個內容：一是資料庫負載如何、效率怎麼樣，二則是這裡面有效能問題的程度到底如何。

傳統上大部分DBA喜歡選擇QPS作為這樣的指標，在我們分析其意義，可以發現QPS並不能完全代表資料庫的效能狀態。QPS是純粹的每秒查詢數、執行數，能直觀看到每秒鐘有多少操作量，簡單計算便能知道哪個資料庫會更繁忙一些。

但如果把它放在衡量效能狀態的層面，每一個操作會有操作的響應時間，需要同時關注運算元與響應時間才能反映真實的效能壓力，而作業系統的對應負載就應該是運算元與操作時間的總數。

這裡不難得到一個時段負載的公式，為“Load=QPS * avg_Latency(平均響應時間) * time(時間)”。但計算後會發現它的值與作業系統的Load對應不上，往往響應時間越大，系統壓力會越大，負載值就越高。

在這種情況下，我們可以確認它其實有很多慢響應的時間，但在我們每一分鐘採集一次的過程中，在採集點的前後有一些語句並沒有被執行完成，而等到執行完以後，這些語句才會被計算QPS。所以如果在你採集的過程中有大量的慢語句，那這部分沒有執行完成的語句就被遺漏了，若仍然使用上面的負載公式計算，那麼慢語句越多，時段負載與OS統計的負載值就相差越大。

這時我們可以引入一個概念：AS/PS，它表示平均每秒執行語句的總負載。它引入了執行中語句時間增長統計，修正了單純計算短查詢負載的誤差，通過驗證，明確了通過在資料庫層面的AS/PS總繁忙度計算，能夠與主機層面統計的系統負載構成關聯。有了資料庫與系統的這一層的聯絡，再進行主機資源與資料庫指標的關聯分析，就變得有意思起來了。

當系統負載升高時，我們能很清晰地分解出到底是哪個資料庫例項推高了負載，可以進一步得知是短查詢暴增還是出現慢語句而影響了負載，再進一步得知到底是被誰觸發了或者到底是哪個語句造成的，這些我們都能夠根據這個思路一一查出。引入這個指標，還可以在這個維度上解決資料庫上浮的問題。

另外一個思路是直觀地根據響應時間評分上浮來明確最應該關注哪個節點。MySQL官方推出的Enterprise Monitor工具提出的QRTi，其實就是面向這一思路。

它實際是用一種評分的標準，我們可以設定一個可接受和不可接受的慢查詢時限，其中預設設定為100-400毫秒之間，小於100毫秒查詢記為1分，100-400毫秒之間的查詢在可接受範圍之內的為0.5分，大於400毫秒不在接受的範圍之內為0分，根據執行次數計算平均值，再乘以百分比，得到了QRTi的結果值。那麼顯而易見，百分比越高就說明這裡面的響應層級越好，而百分比下降就說明這裡面有更多慢響應。

通過這兩個維度，一是它對系統造成的負載壓力大小，二是它實際上有多少個慢響應，就可以很快評估出這個資料庫裡哪些是值得你關注的。根據經驗所能得到的很多情況是，最值得關注的不是QPS最高的資料庫，反而是繁忙度升高、響應度變差的資料庫，而且一般繁忙度升高往往伴隨響應度降低，QPS也會隨之降低。

（2）指標特點對比

下圖列出了QPS、AS/PS、和QRTi的指標特點和優劣勢的對比。

一般而言，當選擇做整個效能評估或效能入口的點時，DBA會比較認可傳統段的QPS，並通過其來接觸資料庫或者評估它的操作總量。從劣勢來看，QPS不能直觀橫向比較資料庫效能問題。

而AS/PS的劣勢在於並不直接與資料庫狀態指標等同，而優勢是與資料庫的執行效能關聯度高，能作為關聯與下鑽過程的關鍵指標。而QRTi僅能衡量慢查詢程度，並不直觀反映效能情況，但根據它能直接下鑽問題SQL。

2. 關聯分析：提供多種場景的分析通路

有了入口指標後，它就可以為我們提供多種場景的分析通路，如指標分解、指標語句關聯、指標對比和時段執行回溯。

（1）指標分解

• 分解獲取效能指標的構成詳情
• 場景舉例：分解AS/PS，發現opening table佔比較多

上圖是我對AS/PS做的分解，其中紅色部分是大量的短查詢語句，根據絕對值來說這是一個繁忙度能達到400%的相當繁忙的資料庫，很多短查詢語句都是在時段內完成的，但仍然有一些語句屬於慢等待。這就證明這裡面其實有很多語句的響應時限在我們的採集範圍間隔之外了，也就是說，如果我現在採集的間隔是1分鐘一次，那很多語句的響應時限間隔是大於5秒、10秒甚至1分鐘的，那我們很自然地就會關注這一部分還有沒有執行耗時很高的情況。

（2）指標語句關聯

• 提供效能指標關聯到語句的分析通路
• 場景舉例：

• 通過臨時表建立率高定位到建立臨時表的語句
• 發現時段內bytes較高，關聯到rows_sent高的語句

上圖中展示的是Bytes_sents系統狀態指標，這裡可以與採集到的語句Rows Snet相關聯，能夠直觀地關聯到具體哪些語句的返回量過高，推高了整個資料庫網路傳送。

（3）指標對比

• 選取不同效能指標按維度進行對比
• 對比方式：

• 同庫不同指標間對比：對比Com_delete與Innodb_rows_deletedu
• 異同庫相關指標對比：對比不同庫的innodb buffer pool命中率
• 同庫不同時段指標對比：對於語句優化後臨時表建立改善情況

在分析過程中也會普遍存在指標對比的需求。

第一個場景發生在同一個資料庫內。假如我希望知道這套資料庫裡有沒有一些大批量的刪除操作和以及這些操作的比例，那隻需要拿Com_delete與Innodb_row_delete關聯在一起，確認一個刪除操作到底對應多少行的刪除。如果這個數非常大，那其實也會存在一些風險。

第二個場景發生在不同庫之間。比如你知道很多庫都有效能問題，但到底哪些庫的受效能指標影響更深呢？那就可以把對應的指標拿出來作對比。

第三個場景是時段的對比。我們會在很多時候發起一些專門優化的週期，而優化週期前後是效能對比，所以可能調整過的語句、前面語句和後面的語句不能一一對應，這時我們也可以做一些對比，很明確的是，此時這個資料庫的效能已經得到了優化。

需要指出，指標和語句的關聯其實是這裡面整個下鑽過程中的核心，傳統的分析手段裡只能分別得到指標、語句，沒有辦法把它們關聯起來。在傳統情況下，如果一個數據庫出了問題，我們可以根據慢日誌看到其中很多查詢時間長的語句是什麼、最早產生的語句是什麼，認為這部分就是對它效能影響最大的語句，這其實是靠經驗推測的一個處理方法。

但如果做到狀態指標跟語句的關聯，我們通過問題指標的上浮，可以馬上下鑽到相關的風險語句，就可以節省分析時間，還可以通過造成的系統負載來判斷不同語句對系統造成的問題的影響度。

（4）時段執行回溯

• 提供歷史時段內的指標和語句回溯
• 場景舉例：回顧過去故障時段的語句執行情況

狀態指標差值計算比較簡單，比如按採集週期在30秒或1分鐘間取值再計算差值，這樣的採集方式很多工具都支援。比較麻煩的是，語句的差值計算可能會存在一些特別的情況，很多語句是週期性執行的，可能這一分鐘有查詢，下一分鐘沒有，再下一分鐘又有，這時你如果只是簡單地做兩個時間週期的差值是不合適的，需要特別處理採集間隔過大的情況。

還有一種情況就是資料庫做了一些重啟的操作，其中部分儲存的資訊可能遺失了，你在第一次獲取時就會得到一個負的差值，這些值也需要特別處理。

我們設計時做了一個語句索引表，因為裡面的ID是唯一的，即便是同一條語句在不同的庫裡也無妨，只要記錄了它曾經出現、最近出現的兩次資料，這樣的設計能較快定位到語句，也比較省儲存空間。

3、 問題點定位：提供更豐富的語句資訊

最後講講我們到底可以做多少針對語句的效能下鑽分析場景。

語句執行效能的採集來源是基於Performance_schema，下面的列表中體現了這一系列的語句執行資訊包括的維度，這些維度都能關聯資料庫狀態指標進行分析。

但比較不好的一點在於它是以語句的模板形式進行儲存的，無論where條件變數是等於1、2、還是3，它仍然是一個模板，需要去專門獲取語句的樣例。有了語句的樣子，特別是特定時段的樣例，就能很好地針對性分析語句執行計劃等執行資訊。

4、圍繞效能管理的其它拓展

這樣的效能管理其實還有很多擴充套件，尤其是我剛提到的SQL樣例。針對語句的樣例，我們可以對語句做一些語法上的分析，把對SQL規範語法稽核引入，又能在上線環節很好地做好應用變更的管控，即稽核應該調整那些不合規的應用新增語句，才允許上線。

往往我們還會發現，很多造成資料庫效能問題的點不僅僅是由於慢語句本身造成的，而是比如由配置不合理等產生，也有可能涉及到表物件本身的容量、碎片過多或者是由於物件存在外來鍵、無索引、甚至無主鍵等情況，這些因素的監控也可以一併考慮。

這種基於效能本身的管理可以圍繞起來做很多事情，希望能從效能管理的點最終擴充套件到資料庫管理、資料庫運維的整個面上來。

結語

問題分析的過程，包括本文所關注的效能分析過程，往往是一個通過工具，結合經驗的沉澱過程。分析問題的手段多種多樣，而沉澱的經驗是可以複製，可以被固化的。在這裡，分享我們沉澱在產品中的分析經驗與方法論，同樣是希望與大家探討一個把MySQL中的原理與使用實踐相結合的思路。

將問題分析的過程自動化甚至智慧化，在資料庫運維中這是極具挑戰的一環。而在資料庫運維經驗沉澱的產品化道路上，我們一直在不斷探索。我們在努力鍛造的正是這樣一款支援主流Oracle、MySQL、SQL Server和DB2各版本資料庫，具備資料庫的專業監控、運維、效能管理，SQL稽核等場景的專業資料庫運維管理平臺。

最後，容許我打個小廣告，簡單展示一下：

原文來自微信公眾號：DBAplus社群