mysql優化方式

在mysql中有乙個專門負責優化select語句的優化器模組，其主要功能是通過計算分析系統中收集的各種統計資訊，為客戶端請求的query給出最優的執行計畫。

（1）優化更需要優化的query

高併發低消耗的query對整個系統的影響高於低併發高消耗的大。所以先優化高併發低消耗的query

（2）永遠用小結果集驅動大的結果集

mysql中join（連線查詢或者子查詢）都是通過巢狀迴圈來實現的。驅動結果集越大，所需要的迴圈越多。驅動結果集是外層迴圈。

（3）盡可能在索引中完成排序

（4）僅用最有效的過濾條件（查詢書中內容）

explain展示執行計畫，profiling展示cpu 記憶體利用率

innodb是b-tree索引

myisam有b-tree索引和full-text索引

經常會有多個字段一起作為查詢過濾條件存在於where子句中。這時必須判斷是在過濾性最好的字段上建立索引，還是在過濾條件單所有欄位上建立乙個組合索引。

組合索引因為有多個字段存在，理論上被更新的可能性肯定比單間索引大很多，帶來的附加成本會高。但是當where字句中查詢條件含有多個欄位時，通過多個字段組成組合索引的查詢效率肯定比單建索引高很多。

多個單建索引的情況也不好。mysql優化器大多數情況下只會選擇其中乙個索引，放棄其他索引。

一般應用中，只要不是其中某個過濾欄位在大多數場景下能過濾90%以上的資料，而且其他過濾欄位會被頻繁更新，一般選擇組合索引

建立索引： create index group_message_author_subject on group_message(author,subject(16)) //組合索引

顯示某個表的索引：show indexes from group_message\g

有時候mysql系統統計資訊不夠完整，會造成他並沒有選擇乙個真正最優的索引，而是選擇了其他查詢效率較低的索引，所以我們必須認為的強制選擇使用索引。 explain select * from group_message force index(idx _group_message_author_subject)where user_id=3 and author ='3' and subject like 'weiurazs%'\g

檢視sql執行時間

mysqlslap --create-schma=example --query "select * from group_message

where user_id=3 and subject like 'weiurazs%' --iterations =10000

結果會顯示出平均時間，最短時間，最長時間

總結：盡量選擇過濾性更好的索引

不要完全相信mysql的queqy optimizer ，可以自己選擇索引

如果可以不認為強制，就不要人為干預，否則不利於維護。

mysql在更新表的column ca的資料的同時，必須跟新column a 的索引資料，最明顯的資源消耗就是增加了更新所帶來的io量和調整索引所致的計算量。索引的儲存也要占用空間，太多的索引會使儲存空間資源消耗增加。

1.永遠用小結果集驅動大結果集

2.優先優化內層迴圈，即保證join語句中被驅動表的join欄位已經被索引。

盡量使用索引字段，甚至可以增加索引字段

group by的實現有三種方式

完全利用索引掃瞄來實現，並不需要掃瞄所有滿足條件單索引建即完成操作。

需要滿足三個條件：

1.groupby條件字段必須處在統一索引中的最前面的連續位置

2.使用group by時只能使用max 和min這連個聚合函式

3.如果引用到該索引中grouup by條件之外的字段條件，它就必須以常亮存在；

當group by 條件欄位並不是索引最前面的索引部分或者不是連續的，不能鬆散型索引掃瞄。但是如果query語句中存在乙個常量值來引用缺失的索引鍵，可以使用緊湊型索引掃瞄。

當group by 條件欄位並不是索引最前面的索引部分或者不是連續的，不能鬆散型索引掃瞄。如果query語句中不存在乙個常量值來

引用缺失

的索引鍵，而是索引建是乙個範圍。那就只能用臨時表實現group by

同group by

mysql優化方式

mysql的優化方式

mysql優化查詢的方式

mysql的優化 MySQL優化

mysql優化方式

mysql的優化方式

mysql優化查詢的方式

mysql的優化 MySQL優化

相關推薦