上周五線上數(shù)據(jù)庫(kù)突然卡死，半夜爬起來(lái)重啟服務(wù)器，這事兒越想越憋屈。數(shù)據(jù)庫(kù)明明加了索引，咋查詢還是吭哧吭哧跟老牛拉破車似的？我尋思著得把MySQL肚子里的彎彎繞搞明白。

從執(zhí)行計(jì)劃開始折騰

打開終端連上數(shù)據(jù)庫(kù)，隨便找了個(gè)慢查詢開刀。敲完EXPLAIN ｓｅｌｅｃｔ FROM user_order WHERE create_time > '2023-01-01';這行命令，蹦出來(lái)一堆花花綠綠的字兒。重點(diǎn)盯著type列看，好家伙寫著ALL，意思就是把整張訂單表當(dāng)洋蔥剝！兩百多萬(wàn)條數(shù)據(jù)全掃一遍，硬盤不抗議才怪。

不死心又查了查索引，發(fā)現(xiàn)create_time字段明明掛著INDEX，咋就不走？翻文檔看到個(gè)冷知識(shí)：范圍查詢后邊的索引都白瞎。比如我這語(yǔ)句帶了個(gè)大于號(hào)，后邊要是再加個(gè)status狀態(tài)字段查詢，索引直接罷工。

• 實(shí)驗(yàn)1：把查詢條件改成WHERE user_id=10086 AND create_time>'2023-01-01'
• 實(shí)驗(yàn)2：掏出force index硬拽著數(shù)據(jù)庫(kù)走時(shí)間索引

結(jié)果第一個(gè)實(shí)驗(yàn)type變成了range，掃描行數(shù)從200萬(wàn)暴跌到3000。至于暴力用force index那招兒，執(zhí)行時(shí)間反而更慢了——優(yōu)化器選的路徑雖然蠢，但硬改道兒可能掉坑里。

被統(tǒng)計(jì)信息坑慘了

第二天突然發(fā)現(xiàn)個(gè)怪事：同個(gè)查詢隔半天執(zhí)行計(jì)劃自己變了。后來(lái)才搞明白優(yōu)化器兜里有本動(dòng)態(tài)賬本，隔三差五抽樣統(tǒng)計(jì)數(shù)據(jù)分布。有回我批量刪了五十萬(wàn)訂單，它還以為表里塞滿數(shù)據(jù)，死腦筋走全表掃描。

直接往數(shù)據(jù)庫(kù)里灌了把雞血：ANALYZE TABLE user_order; 手動(dòng)更新統(tǒng)計(jì)信息。完事兒再explain，優(yōu)化器總算開竅選對(duì)索引了。這玩意兒得定期維護(hù)，跟汽車換機(jī)油一個(gè)理兒。

聯(lián)合索引翻車現(xiàn)場(chǎng)

第三天想著弄個(gè)高級(jí)貨——聯(lián)合索引。給user_id和status倆字段建了個(gè)INDEX，美滋滋覺得能起飛。結(jié)果執(zhí)行ｓｅｌｅｃｔ FROM user_order WHERE status=1;當(dāng)場(chǎng)傻眼：type還是ALL！這才知道聯(lián)合索引跟查戶口似的，沒帶頭大哥user_id查status就裝瞎。

改索引順序也沒轍，只能拆開建兩個(gè)單字段索引。虧得這張表寫操作少，不然索引太多反而拖慢寫入速度。

實(shí)戰(zhàn)真香時(shí)刻

壓軸拿真實(shí)業(yè)務(wù)開刀：活動(dòng)頁(yè)用戶訂單查詢，原先要8秒。翻出SQL一瞅，不僅亂用OR連接條件，還帶著五六層子查詢嵌套。直接動(dòng)手：

• 把OR全拆成UNION分治
• 子查詢改寫成JOIN
• 凌晨自動(dòng)更新熱數(shù)據(jù)統(tǒng)計(jì)

改完讓業(yè)務(wù)同事點(diǎn)按鈕，加載時(shí)間直接砍到0.3秒。產(chǎn)品經(jīng)理端著奶茶過(guò)來(lái)夸人時(shí)，突然覺得這幾天熬夜掉的頭發(fā)真值。

說(shuō)句大實(shí)話：數(shù)據(jù)庫(kù)調(diào)優(yōu)跟中醫(yī)把脈似的，不能光背索引口訣。多explain看執(zhí)行計(jì)劃，慢日志常備著，有事沒事跑跑ANALYZE，比網(wǎng)上那些玄學(xué)優(yōu)化教程管用一百倍。