前言

作為后端開發工程師，我們經常會遇到數據庫查詢性能問題。在一次系統優化中，我發現一個簡單的索引順序調整竟然讓查詢速度提升了10倍！這讓我意識到復合索引列順序的重要性。今天，我就來分享一下這個經驗，希望能幫助大家避免類似的性能陷阱。

一次真實的性能優化經歷

上周，我接手優化一個運行緩慢的訂單查詢接口。原查詢如下：

SELECT * FROM orders 
WHERE create_time > '2023-01-01' 
AND status = 'completed'
ORDER BY amount DESC
LIMIT 100;

這個查詢在百萬級數據表中需要3秒多才能返回結果，明顯不符合要求。

問題分析

我先用EXPLAIN查看了執行計劃：

EXPLAIN SELECT * FROM orders 
WHERE create_time > '2023-01-01' 
AND status = 'completed'
ORDER BY amount DESC
LIMIT 100;

結果顯示數據庫進行了全表掃描，使用了filesort排序。原來表上只有一個索引：

INDEX idx_create_time_status (create_time, status)

解決方案

根據復合索引的最佳實踐，我調整了索引列的順序：

DROP INDEX idx_create_time_status ON orders;
CREATE INDEX idx_status_create_time ON orders(status, create_time);

再次執行查詢，響應時間從3秒多降到了300毫秒左右！

為什么這樣有效？

1. 等值條件優先原則

• status = 'completed'是等值查詢

• create_time > '2023-01-01'是范圍查詢

數據庫能更高效地使用等值條件過濾數據。在我們的案例中，completed狀態的訂單只占總量的10%，先過濾這部分數據大大減少了需要處理的數據量。

2. 范圍查詢的"阻斷"效應

當范圍查詢列在前時，后面的列通常無法有效使用索引。而等值列在前時，范圍查詢仍然可以利用索引。

3. 覆蓋索引優勢

新索引還能支持這樣的查詢：

SELECT status, create_time FROM orders 
WHERE status = 'completed' 
AND create_time > '2023-01-01';

這個查詢可以完全通過索引完成，無需訪問表數據。

實際應用建議

1. 分析查詢模式：使用慢查詢日志找出高頻查詢

2. 檢查執行計劃：EXPLAIN是必備工具

3. 考慮選擇性：高選擇性的等值條件列應該靠前

4. 權衡索引數量：不是越多越好，每個索引都有維護成本

常見誤區

1. 盲目添加單列索引：不如設計好的復合索引有效

2. 忽視列順序：以為只要包含這些列就行

3. 過度索引：為每個查詢都創建獨立索引

總結

通過這個案例，我深刻理解了復合索引列順序的重要性。記住這個簡單的原則：等值查詢列在前，范圍查詢列在后，往往能帶來意想不到的性能提升。

你在索引優化方面有什么經驗或問題？歡迎在評論區分享交流！