Mysql性能優化筆記

一，索引

1.Innodb索引使用的是B+樹

2.儘可能簡化where條件，好比不要出現 where id + 3 = 5,這沒法使用索引

3.索引很大時，能夠冗餘一列來模擬哈希索引

4.小的表不須要使用索引，很大的表須要用分塊技術，也不用索引

5.索引的選擇性=不重複的數量/總的數量

選擇性越高，效率越高，unique索引選擇性爲1，效率最好

對於blob，text，很長的varchar類型的列，必須使用前綴索引。

訣竅在於，要選擇足夠長的前綴以保證較高的選擇性，同時又不能太長

建立前綴索引：(city列里長度爲7的前綴索引)

alter table sakila.city_demo ADD KEY(city(7))

前綴索引的缺點，沒法作ORDER BY和GROUP BY

後綴索引：mysql不支持反向索引，但能夠把字符串反轉後存儲，並基於此創建索引，能夠經過觸發器來維護索引

 

六、多列索引

對多個列作相交操做（and）時，須要的時一個多列索引而不是多個單獨的單列索引

若是在explain中看到有索引合併，應該好好檢查一下查詢和表單結構，

能夠經過參數optimizer_switch來關閉索引合併

 

7.覆蓋索引

若是一個索引包含全部須要查詢的字段的值，咱們就稱之爲覆蓋索引

因爲myISAM在內存中只存索引，因此用覆蓋索引有嚴重的性能問題

因爲InnoDB的聚簇索引，覆蓋索引對InnoDB特別有用

另外，只能用B-tree索引作全文索引

當使用覆蓋索引時，EXPLAIN 中的Extra中顯示Using index

 

 

查詢優化

通常的優化方法有兩個

1.確認應用程序是否在檢索大量超過須要的數據，這一般意味着訪問了太多的行

但有時候也多是訪問了太多的列

2.確認MySQL服務器層是否在分析大量超過須要的數據行

解決方法，加limit，

若是數據庫資源緊張，能夠考慮用mybatis代替hibernate

取出所有列，會讓優化器沒法完成覆蓋索引掃描這類優化，好比hibernate

不過獲取全部列的查詢緩存，比多個獨立的只獲取部分列的查詢緩存更有好處

每次看到select * 請去懷疑一下是否真的須要所有取出 

重複查詢相同的數據：請把這個數據緩存起來，好比放到session中

 

最簡單的衡量查詢開銷的三個指標：

響應時間，

掃描的行數

返回的行數

這三個指標都會記錄到mysql的慢日誌中，因此檢查慢日誌

若是發現查詢須要掃描大量的數據行，但返回少許的行，那麼能夠嘗試下面的技巧去優化它

1，使用索引覆蓋掃描，把全部須要用的列都放到索引中

2.改變表結構，例如使用單獨的彙總表

3.重寫這個查詢，各類優化

 

有時能夠考慮將一個複雜查詢分爲多個小查詢，若是能減小工做量的話

好比刪除舊的數據，每次刪一點，能夠避免一次鎖住不少數據

 

分解關聯查詢的好處

一、緩存效率更高

二、用返回的數據的id來進行順序查詢比用join進行隨機關聯效率更高

壞處：一條語句分多條，增長鏈接開銷

 

 排序優化

不管如何，排序都是一個成本很高的操做，因此從性能角度考慮，儘量避免排序，或避免對大量數據進行排序