某業務系統出現連鎖阻塞,根因是 dateline 索引誤導優化器選錯執行計劃。刪除該索引後,慢查詢從 480 秒降至毫秒級,5000 條阻塞查詢瞬間消失。本文記錄發現、對比、決策、驗證全過程。
現象描述
- 時間窗:2014-03-12 15:39:01 – 15:55:00
- 某慢查詢執行極慢,阻塞後續本應極快的查詢
- 出現 ~5000 條
Query 相互阻塞
根因分析
- 表存在
dateline 索引
- 優化器選擇走
dateline 索引 → 執行計劃極差
- 實際查詢不需按時間範圍過濾,全表掃描反而更快
執行計劃對比
| 指標 | 走 dateline 索引 | 不走索引 (全表掃描) |
| 掃描行數 | 數百萬 | 數百萬 (但序列讀取) |
| 執行時間 | > 300 秒 | < 0.1 秒 |
| 阻塞連鎖 | 5000+ 查詢 | 無 |
決策與執行
-- 確認無其他查詢使用此索引後
ALTER TABLE biz_table DROP INDEX dateline;
⚠️ 初期擔心影響其他查詢,觀察一段時間確認**無其他查詢使用此索引**。
驗證結果
- ✅ 目標慢查詢:480秒 → < 0.1秒
- ✅ 連鎖阻塞:5000+ → 0
- ✅ 系統吞吐:恢復正常
- ✅ 觀察期內:無其他查詢回歸
核心心法
索引是好東西,但**不該存在的索引就是負擔**。
定期檢視 sys.schema_unused_indexes (5.7+) 或 pt-index-usage,清理無用索引。
索引維護檢查清單
- 🔍 定期分析
SHOW INDEX / sys.schema_unused_indexes
- 🔍 關注
Cardinality 低(選擇性差)的索引
- 🔍 慢查詢日誌中
key 欄位頻繁出現但 rows 極大的索引
- 🔍 寫入密集表的非必要索引(每個索引 = 寫入開銷)
- ✅ 刪除前驗證:
EXPLAIN 對比、業務低峰期、可回滾
- 上一篇文章: MySQL DATE 型別完整指南:格式標準、寬鬆輸入、比較規則、特殊 0 日期、ODBC 相容
- 下一篇文章: MySQL SQL 優化實戰:關聯子查詢效能陷阱與改寫策略
Copyright ©
程式碼之家 All Rights Reserved