該篇是sql優化的第4篇。
這裡主要表達我的乙個觀點是：不該存在的索引就該乾掉，留著礙事
在2014-3-12 15:39:01 -- 15:55:00這段時間內，在某個業務系統我們發現2個問題：
這種現象在資料庫中實際也是很常見，就是某個慢查詢，始作俑者，執行特馬慢，把後面本該很快的查詢給堵住，導致系列長查詢出現
經診斷，我們發現某張表裡存在dateline索引，該索引會讓mysql優化器選擇錯了執行計畫，導致後續大量sql擁堵，大概有5000條query相互堵住
如果不走dateline索引，效果很好，下面對比：
1. 執行計畫對比
2. 執行時間對比：
因此，我們給開發童鞋的反饋是，卡擦掉dateline索引
起初我們並不知道該索引是否還提供給其他query使用，所以膽戰心驚害怕會引起其他查詢變慢
不過經過這段時間的觀察，實際上，並沒有其他查詢在使用這條索引
索引是好東西，但不要貪哦
good luck！
MYSQL SQL優化流程
常去想想以前的東西，懷舊不是用感傷的，是溫故知新，加油！1 盡量將複雜的sql拆成幾個簡單的查詢 2 盡量使用表連線，減少使用過 in not in 3 儘量減少子查詢的使用或者將其合併出來 4 盡量將 in not in exists not exists變為 join 語句，減少 合併子查詢 1...
MySQL SQL語句優化
檢視表定義 show create table users 檢視表的索引 show index from users 你要獲取第乙個表的所有資訊，你說全表掃瞄快呢還是索引掃瞄快呢？所以當你查詢庫 包括left join中的臨時庫 的所有資訊時，資料庫會選擇最優方法 全表掃瞄！s表dept id na...
Mysql sql查詢優化
1.單個條件未加索引 對應的執行計畫 從查詢計畫中可以看出該查詢全表掃瞄，掃瞄行數 9000多行 2.增加唯一索引之後查詢 查詢時間縮短，然後再看查詢計畫 查詢計畫中，掃瞄行數中只有一行。上面建立的索引是唯一索引，常規索引中查詢計畫的type一般為ref 索引列和非索引列一起查詢，索引仍然會有效 單...