MySQL 索引最佳化原則

標籤：很多   沒有   delete   無法   否則   請求   break   bsp   避免   

一、索引最佳化原則1、最左首碼匹配原則，聯合索引，mysql會從做向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。 2、=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢最佳化工具會幫你最佳化成索引可以識別的形式 3、索引列不能參與計算，保持列“乾淨”，比如 from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的欄位值，但進行檢索時，需要把所有元素都應用函數才能比較，顯然成本太大。所以語句應該寫成 create_time = unix_timestamp(’2014-05-29’) 4、使用索引時，索引欄位最好小而且唯一，避免select * 的情況 5、盡量的擴充索引，不要建立索引。比如表中已經有a的索引，現在要加(a,b)的索引，那麼只需要修改原來的索引即可，建立不必要索引會增加MySQL空間 6、如果確定有多少條資料，使用 limit 限制一下，MySQL在尋找到對應條數的資料的時候，會停止繼續尋找 7、利用查詢快取，很多時候MySQL會對查詢結果進行cache，但是對應“動態”的資料會不cache，例如： 1 SELECT username FROM user WHERE signup_date >= CURDATE() 無法使用cache2 SELECT username FROM user WHERE signup_date >= ‘2017-05-06‘ 可以cache  當使用了MySQL的一寫函數之後，MySQL無法確定結果是易變的，所以不會cache，還有now(),rand()也一樣不開啟cache 8、join 文法，盡量將小的表放在前面，在需要on的欄位上，資料類型保持一致，並設定對應的索引，否則MySQL無法使用索引來join查詢 9、在大表上做大量更新時，如果會鎖全表，則需要拆分執行，避免長時間鎖住表，導致其他請求積累太多（InnoDB 支援行鎖，但前提是Where子句需要建立索引，沒有索引也一樣是鎖全表）

 1 while (1) { 2     //每次只做1000條 3    mysql_query("DELETE FROM logs WHERE log_date <= ‘2009-11-01‘ LIMIT 1000"); 4    if (mysql_affected_rows() == 0) { 5         // 沒得可刪了，退出！ 6         break; 7     } 8     // 每次都要休息一會兒 9     usleep(50000);10 }

 

MySQL 索引最佳化原則