首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫

MySQL SQL 優化實戰:誤導優化器的索引 — 刪除 dateline 索引消除 5000 條阻塞查詢

     編輯:MySQL 資料庫相關知識

某業務系統出現連鎖阻塞,根因是 dateline 索引誤導優化器選錯執行計劃。刪除該索引後,慢查詢從 480 秒降至毫秒級,5000 條阻塞查詢瞬間消失。本文記錄發現、對比、決策、驗證全過程。

現象描述

  • 時間窗:2014-03-12 15:39:01 – 15:55:00
  • 某慢查詢執行極慢,阻塞後續本應極快的查詢
  • 出現 ~5000 條 Query 相互阻塞

根因分析

  • 表存在 dateline 索引
  • 優化器選擇走 dateline 索引 → 執行計劃極差
  • 實際查詢不需按時間範圍過濾,全表掃描反而更快

執行計劃對比

決策與執行

-- 確認無其他查詢使用此索引後
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 對比、業務低峰期、可回滾
  1. 上一篇文章:
  2. 下一篇文章:
Copyright © 程式碼之家 All Rights Reserved
指標走 dateline 索引不走索引 (全表掃描)
掃描行數數百萬數百萬 (但序列讀取)
執行時間> 300 秒< 0.1 秒
阻塞連鎖5000+ 查詢無