今天想嘮嘮MySQL索引優(yōu)化的事兒。上周線上庫突然抽風(fēng)，慢查詢報(bào)警嘀嘀嘀響個(gè)不停，DBA直接在群里@我，那叫一個(gè)尷尬！趕緊翻手冊(cè)找工具，折騰一圈總算穩(wěn)住了場(chǎng)面。直接上干貨，記錄下我用過的三款實(shí)用家伙事兒。

瞎折騰的開端

問題出在老訂單查詢接口上。用戶一多，頁面加載直接轉(zhuǎn)圈圈半分鐘，后臺(tái)日志里堆滿了"using filesort"和"using temporary"。我蹲電腦前薅頭發(fā)，心想索引明明建了？于是打開命令行，先拿自帶的EXPLAIN懟上去：

敲命令：

EXPLAIN ｓｅｌｅｃｔ FROM orders WHERE user_id=123 AND status='paid' ORDER BY create_time DESC;

結(jié)果一看傻眼了——type列顯示ALL，這玩意兒居然在掃全表！紅著臉檢查表結(jié)構(gòu)，發(fā)現(xiàn)user_id和status字段確實(shí)單獨(dú)建了索引，但排序字段create_time孤零零的沒搭伙。怪不得慢成狗。

慢查詢?nèi)罩就诘V

光優(yōu)化這一條不夠，鬼知道還有多少慢查詢藏著。這時(shí)候搬出mysqldumpslow，這工具能扒拉MySQL的慢查詢?nèi)罩?。先在配置文件里?strong>slow_query_log打開，熬到半夜攢夠日志，直接運(yùn)行：

敲命令：

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

屏幕唰唰跳出前十條慢查詢：

• 第一條：商品搜索聯(lián)合查詢耗時(shí)8秒
• 第二條：用戶畫像統(tǒng)計(jì)卡了6秒

最坑的是第三條，某個(gè)后臺(tái)job每小時(shí)跑一次的報(bào)表SQL，居然沒！用！索！引！難怪監(jiān)控總顯示CPU半夜飆高。

升級(jí)打怪上專業(yè)工具

查完基礎(chǔ)問題手癢，想搞點(diǎn)深度優(yōu)化。同事甩來個(gè)pt-query-digest（這名字真拗口）。裝的時(shí)候踩了坑：得先配perl環(huán)境，缺個(gè)DBD::mysql模塊折騰半小時(shí)。跑起來倒是爽快：

敲命令：

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

打開報(bào)告直接驚呆——這玩意兒把SQL解剖得明明白白：

• 每條SQL耗時(shí)占比用餅圖畫出來
• 鎖等待時(shí)間標(biāo)紅警告
• 連"建議加組合索引(user_id,status)"都直接拍臉上

照著報(bào)告改了五個(gè)關(guān)鍵索引，重啟服務(wù)后監(jiān)控曲線肉眼可見地趴下來了。

血淚總結(jié)

實(shí)踐完徹底悟了：

• EXPLAIN是隨身匕首，隨時(shí)掏出來看SQL執(zhí)行計(jì)劃
• mysqldumpslow像洛陽鏟，專門掘慢查詢?nèi)罩镜膲?/li>
• pt-query-digest堪稱核武器，直接轟出優(yōu)化方案

但工具再牛也得帶腦子用。有回我愣給字符串字段加組合索引，工具沒報(bào)錯(cuò)，結(jié)果磁盤空間一夜爆滿……所以說，索引不是銀彈，關(guān)鍵還得搞清楚業(yè)務(wù)查詢模式?，F(xiàn)在看慢查詢監(jiān)控終于不心虛了，甚至有點(diǎn)盼著報(bào)警——這不又逮到機(jī)會(huì)給老板展示優(yōu)化成果了嘛（漲薪有望兄弟們）！