前幾天真是被數(shù)據(jù)庫折騰得夠嗆，我那破站訪問量稍微漲了點，頁面加載就卡得跟拖拉機似的。打開后臺一看，好家伙，MySQL CPU動不動就飆到90%以上，內(nèi)存也吃緊。這不行，得趕緊找找毛病在哪。

第一步：掏出數(shù)據(jù)庫自帶的老家伙

我尋思著先用用MySQL自帶的工具試試水。慢查詢?nèi)罩韭锢鲜烊肆耍苯釉谂渲梦募锛由线@幾行：

• slow_query_log = 1
• slow_query_log_file = /var/log/mysql/*
• long_query_time = 2

重啟數(shù)據(jù)庫，還真行！等了一天，日志文件里就躺了一堆慢查詢。趕緊用mysqldumpslow這個命令瞅瞅：

mysqldumpslow -s t /var/log/mysql/* more

結果出來一堆數(shù)字和SQL片段，看得我眼睛都花了。確實抓到了幾個查詢時間特別長的語句，比如有個統(tǒng)計用戶數(shù)據(jù)的聯(lián)合查詢慢得離譜。但問題來了，這工具只告訴你哪條慢，沒說為啥慢！像是讀代碼不費勁（索引）到底行不行，它可不管。

第二步：試試免費的開源伙計

自帶工具不給力，我就琢磨搞個開源工具試試。聽說過一個叫Percona Toolkit的玩意兒，口碑不錯。結果安裝就給我來了個下馬威，依賴關系折騰了快一個鐘頭，配環(huán)境變量差點把鍵盤敲出火星子。

好不容易裝好了，用了它家的pt-query-digest來分析之前的慢日志：

pt-query-digest /var/log/mysql/* > slow_*

打開報告一看，嚯！比mysqldumpslow強多了！它不光把慢查詢排了個名，還詳細列出了每個查詢執(zhí)行了多少次、花了總共多少時間，甚至能給出建議“解釋計劃”（EXPLAIN）的提示?？克矣志境鰜韼讉€藏在犄角旮旯、執(zhí)行次數(shù)超多、累加時間很長的查詢。這報告還是太技術了，得自己琢磨索引咋建、SQL咋改。最關鍵的是，沒法直接看到改動后有沒有效果。

第三步：瞄了眼商業(yè)版大炮

前兩個工具用下來，感覺離目標還是差口氣。有朋友攛掇我試試商業(yè)工具，比如某廠的那個知名性能管理平臺（名字就不提了，免得像打廣告）。我抱著好奇心去官網(wǎng)瞅了眼，功能是真心全乎：實時監(jiān)控數(shù)據(jù)庫狀態(tài)圖、自動診斷問題、還能預估改了索引或者SQL能提升多少性能。

它那個界面做得是真漂亮，點點鼠標就能定位瓶頸是哪個庫、哪張表、哪條SQL。甚至還能模擬出如果加了某個索引，查詢速度大概能快多少秒，這就很直觀了！

可當我看到價格表的時候……好家伙，心跳差點停了！對我這小破站和個人博主來說，這錢花得是真肉疼，感覺就像為了修家里漏水的水龍頭，結果請了個工程隊來。

咋辦的？

折騰一圈下來，明白了點門道：

• 慢查詢?nèi)罩竞蚼ysqldumpslow：適合緊急抓個典型，不花一分錢，但效果嘛……聊勝于無。
• Percona Toolkit這類開源工具：免費又夠專業(yè)，能挖得更深，前提是你得耐著性子配環(huán)境、看報告，自己動手能力要強。
• 商業(yè)性能工具：確實省心又全面，效果一目了然，但那是真金白銀堆出來的，小項目或者個人玩玩，錢包遭不住。

我現(xiàn)在嘛常規(guī)就靠Percona Toolkit + 慢日志搭配著用，零成本，麻煩點就麻煩點。真遇到頭疼腦熱的大問題，短租幾天那個商業(yè)大炮來集中處理下，也算能接受。說到底，選工具不是越貴越也不是功能越花哨越得看自己口袋里幾個錢、手上幾把刷子！湊合著能用就得了！