MySQL性能調優總結

時間 2019-11-08

標籤 mysql 性能總結欄目 MySQL 简体版

原文原文鏈接

MyISAM表鎖優化建議

用表級鎖定在鎖定實現的過程當中比實現行級鎖定或者頁級鎖所帶來的
附加成本都要小，鎖定自己所消耗的資源也是最少。可是因爲鎖定的顆粒度比較到，因此形成鎖定資源
的爭用狀況也會比其餘的鎖定級別都要多，從而在較大程度上會下降併發處理能力。
一、縮短鎖定時間
惟一的辦法就是讓咱們的Query執行時間儘量的短。
a) 盡兩減小大的複雜Query，將複雜Query分拆成幾個小的Query分佈進行；
b) 儘量的創建足夠高效的索引，讓數據檢索更迅速；
c) 儘可能讓MyISAM存儲引擎的表只存放必要的信息，控制字段類型；
d) 利用合適的機會優化MyISAM表數據文件；
二、分離能並行的操做
說到MyISAM的表鎖，並且是讀寫互相阻塞的表鎖，可能有些人會認爲在MyISAM存儲引擎的表上就只
能是徹底的串行化，沒辦法再並行了。你們不要忘記了， MyISAM的存儲引擎還有一個很是有用的特性，
那就是Concurrent Insert（併發插入）的特性。
MyISAM存儲引擎有一個控制是否打開Concurrent Insert功能的參數選項： concurrent_insert，可
以設置爲0， 1 或者2。三個值的具體說明以下：
a) concurrent_insert=2，不管 MyISAM 存儲引擎的表數據文件的中間部分是否存在由於刪除數據
而留下的空閒空間，都容許在數據文件尾部進行Concurrent Insert;
b) concurrent_insert=1，當 MyISAM存儲引擎表數據文件中間不存在空閒空間的時候，能夠從文
件尾部進行Concurrent Insert;
c) concurrent_insert=0，不管 MyISAM 存儲引擎的表數據文件的中間部分是否存在由於刪除數據
而留下的空閒空間，都不容許Concurrent Insert。
三、合理利用讀寫優先級
在本章各類鎖定分析一節中咱們瞭解到了 MySQL的表級鎖定對於讀和寫是有不一樣優先級設定的，默
認狀況下是寫優先級要大於讀優先級。因此，若是咱們能夠根據各自系統環境的差別決定讀與寫的優先
級。若是咱們的系統是一個以讀爲主，並且要優先保證查詢性能的話，咱們能夠經過設置系統參數選項
low_priority_updates=1，將寫的優先級設置爲比讀的優先級低，便可讓告訴 MySQL 儘可能先處理讀請
求。固然，若是咱們的系統須要有限保證數據寫入的性能的話，則能夠不用設置 low_priority_updates
參數了算法

Innodb行鎖優化建議

Innodb存儲引擎因爲實現了行級鎖定，雖然在鎖定機制的實現方面所帶來的性能損耗可能比表級鎖
定會要更高一些，可是在總體併發處理能力方面要遠遠優於MyISAM的表級鎖定的。當系統併發量較高的
時候， Innodb的總體性能和MyISAM相比就會有比較明顯的優點了。可是， Innodb的行級鎖定一樣也有其脆弱的一面，當咱們使用不當的時候，可能會讓Innodb的總體性能表現不只不能比MyISAM高，甚至可能會更差。數據庫

要想合理利用Innodb的行級鎖定，作到揚長避短，咱們必須作好如下工做：
a) 儘量讓全部的數據檢索都經過索引來完成，從而避免Innodb由於沒法經過索引鍵加鎖而升級
爲表級鎖性能優化

b) 合理設計索引，讓Innodb在索引鍵上面加鎖的時候儘量準確，儘量的縮小鎖定範圍，避免
形成沒必要要的鎖定而影響其餘Query的執行；
c) 儘量減小基於範圍的數據檢索過濾條件，避免由於間隙鎖帶來的負面影響而鎖定了不應鎖定
的記錄；
d) 儘可能控制事務的大小，減小鎖定的資源量和鎖定時間長度；
e) 在業務環境容許的狀況下，儘可能使用較低級別的事務隔離，以減小 MySQL由於實現事務隔離級
別所帶來的附加成本；
因爲Innodb的行級鎖定和事務性，因此確定會產生死鎖，下面是一些比較經常使用的減小死鎖產生機率
的的小建議，讀者朋友能夠根據各自的業務特色針對性的嘗試：
a) 相似業務模塊中，儘量按照相同的訪問順序來訪問，防止產生死鎖；
b) 在同一個事務中，儘量作到一次鎖定所須要的全部資源，減小死鎖產生機率；
c) 對於很是容易產生死鎖的業務部分，能夠嘗試使用升級鎖定顆粒度，經過表級鎖定來減小死鎖
產生的機率網絡

Query優化思路

Query 語句的優化思路和原則：
1. 優化更須要優化的Query；
2. 定位優化對象的性能瓶頸；
3. 明確的優化目標；
4. 從 Explain 入手；
5. 多使用profile
6. 永遠用小結果集驅動大的結果集；
7. 儘量在索引中完成排序；
8. 只取出本身須要的Columns；
9. 僅僅使用最有效的過濾條件；
10. 儘量避免複雜的Join和子查詢併發

索引的利處：

提升數據檢索的效率，下降數據庫的IO成本，加快檢索時間，下降檢索過程當中所須要讀取的數據量。函數

下降數據的排序成本，排序字段恰好與索引字段一致。oop

索引的弊端：

索引的建立，索引的更新，會帶來資源消耗問題。性能

索引創建條件：

◆ 較頻繁的做爲查詢條件的字段應該建立索引；
◆ 惟一性太差的字段不適合單首創建索引，即便頻繁做爲查詢條件；
◆ 更新很是頻繁的字段不適合建立索引；
◆ 不會出如今 WHERE 子句中的字段不應建立索引；優化

適合索引的建議：

1. 對於單鍵索引，儘可能選擇針對當前 Query 過濾性更好的索引；
2. 在選擇組合索引的時候，當前 Query 中過濾性最好的字段在索引字段順序中排列越靠前越好；
3. 在選擇組合索引的時候，儘可能選擇能夠可以包含當前 Query 的 WHERE 子句中更多字段的索
引；
4. 儘量經過分析統計信息和調整 Query 的寫法來達到選擇合適索引的目的而減小經過使用
Hint 人爲控制索引的選擇，由於這會使後期的維護成本增長，同時增長維護所帶來的潛在風險spa

MySQL 中索引使用相關的限制

1. MyISAM存儲引擎索引鍵長度總和不能超過1000字節；
2. BLOB和TEXT類型的列只能建立前綴索引；
3. MySQL 目前不支持函數索引；
4. 使用不等於（ != 或者 <>）的時候 MySQL 沒法使用索引；
5. 過濾字段使用了函數運算後（如abs(column)）， MySQL沒法使用索引；
6. Join 語句中 Join 條件字段類型不一致的時候 MySQL 沒法使用索引；
7. 使用 LIKE 操做的時候若是條件以通配符開始（'%abc...'） MySQL 沒法使用索引；
8. 使用非等值查詢的時候 MySQL 沒法使用 Hash 索引；
9.在咱們使用索引的時候，須要注意上面的這些限制，尤爲是要注意沒法使用索引的狀況，由於這很
容易讓咱們由於疏忽而形成極大的性能隱

Join 的實現原理及優化思路

Join 語句的優化

1. 儘量減小 Join 語句中的 Nested Loop 的循環總次數；如何減小 Nested Loop 的循環總次數？最有效的辦法只有一個，那就是讓驅動表的結果集儘量的小。用小的結果集驅動大的結果集。

2. 優先優化Nested Loop 的內層循環；
不只僅是在數據庫的 Join 中應該作的，實際上在咱們優化程序語言的時候也有相似的優化原則。內層循環是循環中執行次數最多的，每次循環節約很小的資源，在整個循環中就能節約很大的資源。
3. 保證 Join 語句中被驅動表上 Join 條件字段已經被索引；
4. 當沒法保證被驅動表的 Join 條件字段被索引且內存資源充足的前提下，不要太吝惜 JoinBuffer 的設置

order by 優化

MySQL 目前能夠經過兩種算法來實現數據的排序操做。
1. 取出知足過濾條件的用於排序條件的字段以及能夠直接定位到行數據的行指針信息，在 Sort Buffer 中進行實際的排序操做，而後利用排好序以後的數據根據行指針信息返回表中取得客戶端請求的其餘字段的數據，再返回給客戶端；
2. 根據過濾條件一次取出排序字段以及客戶端請求的全部其餘字段的數據，並將不須要排序的字段存放在一塊內存區域中，而後在 Sort Buffer 中將排序字段和行指針信息進行排序，最後再利用排序後的行指針與存放在內存區域中和其餘字段一塊兒的行指針信息進行匹配合並結果集，再按照順序返回給客戶端；

Group by優化

兩種優化思路：
1. 儘量讓 MySQL 能夠利用索引來完成 GROUP BY 操做，固然最好是鬆散索引掃描的方式最佳。
在系統容許的狀況下，咱們能夠經過調整索引或者調整 Query 這兩種方式來達到目的；
2. 當沒法使用索引完成 GROUP BY 的時候，因爲要使用到臨時表且須要 filesort，因此咱們必須
要有足夠的 sort_buffer_size 來供 MySQL 排序的時候使用，並且儘可能不要進行大結果集的 GROUP
BY 操做，由於若是超出系統設置的臨時表大小的時候會出現將臨時表數據 copy 到磁盤上面再進行
操做，這時候的排序分組操做性能將是成數量級的降低