資料庫優化之復合索引不起作用的原因

1，情景描述：最近在做資料統計這一塊，有乙個功能然後使用起來覺得非常卡，然後就開始找所在原因。

2，查詢原因

1,把sql語句列印出來放到mysql工具中執行，發現了有一條語句執行的非常慢，目標鎖定此sql

2,查詢關於如何優化sql的相關資料，基本上可確定為索引問題

3，檢視表字段，表中已設復合索引，但為何復合索引沒起到作用

4,後來查資料得知：原來在復合索引中只有最左側會起到作用

4，復合索引的建立原則：

1，如果你很可能僅對乙個列多次執行搜尋，則該列應該是復合索引中的第一列。如果您很可能對乙個兩列索引中的兩個列執行單獨的搜尋，則應該建立另乙個僅包含第二列的索引。

2，包含多個列的主鍵始終會自動以復合索引的形式建立索引，其列的順序是它們在表定義中出現的順序，而不是在主鍵定義中指定的順序。在考慮將來通過主鍵執行的搜尋，確定哪一列應該排在最前面。

,3，請注意，建立復合索引應當包含少數幾個列，並且這些列經常在select查詢裡使用。在復合索引裡包含太多的列不僅不會給帶來太多好處。而且由於使用相當多的記憶體來儲存復合索引的列的值，其後果是記憶體溢位和效能降低。

mysql資料庫復合索引

mysql資料庫中一張user表中,其中包含欄位a,b,c,字段型別如下 a int,b int,c int根據欄位a,b,c按照abc順序建立復合索引idx a b c,以下查詢語句中使用到索引idx a b c的語句有哪些？因復合索引為idx a b c，所以查詢條件只能是在a,ab,abc,a...

偶然間的發現，索引不起作用以及強制使用索引

一次同事反映說他有一條sql的處理時間很長，快20s才能處理完 如圖 查詢時間為19s，最外層dg pushcert表的資料量為10w多，資料量不是很多。此時想到的就是索引問題。之後，同事加上索引以後，發現沒什麼變化，還是原來的處理時間。這就蒙了。單拿出來 select date,to usrid,...

資料庫索引 索引優化

二 三星索引 三 合適設計理想索引 謂詞簡單謂詞和複雜謂詞 where字句中的每個條件稱為乙個謂詞。過濾因子 描述了謂詞的選擇性，即表中滿足謂詞條件的記錄行數所佔的比例 過濾因子 ff 結果集的數量 錶行的數量 平均過濾因子 1 不同列值的數量 索引片及匹配列 乙個索引定義乙個索引片，如果where...