MySQL索引優化案例：單列索引陷阱與複合索引破局

初始嘗試：單列userid索引

為優化WHERE userid='7mini' ORDER BY clicks DESC LIMIT 10，先建立userid單列索引。執行計劃顯示：type=ref，rows=8，雖有Using filesort，但結果集極小，性能可接受。

數據傾斜暴露隱患

換用userid='admin'查詢時，同樣走userid索引，但rows暴增至2944。這2944行全需讀入內存filesort，並發下效能驟降。核心問題在於：單列索引無法同時滿足過濾與排序。

嘗試添加clicks索引並強制使用

建立clicks索引後，MySQL優化器仍選擇userid索引（possible_keys含兩者但key仍為userid）。強制USE INDEX(clicks)並加clicks>10條件：

EXPLAIN SELECT * FROM imgs USE INDEX (clicks) 
WHERE userid='admin' AND clicks > 10 
ORDER BY clicks DESC LIMIT 10;

結果集反增至5455行（type=range），且失去userid過濾優勢，得不償失。

關鍵洞見

• MySQL單表單查詢只能使用一個索引（MySQL 5.0前更嚴格）
• 優化器選擇不一定最優，需人工干預或重寫SQL
• 單列索引難以兼顧WHERE過濾與ORDER BY排序

這為後續引入(userid, clicks)複合索引埋下伏筆——複合索引能同時服務過濾與有序掃描，是解決此類問題的標準路徑。