解決Mysql(MyISAM)的讀寫互斥鎖的問題

最近因為資料庫讀的請求增加，出現了比較嚴重的讀寫鎖問題，由於主從分離，主伺服器很快的執行完了寫入的操作，但從庫由於有大量的select的查詢，會被這些來自主輔同步的update,insert嚴重堵塞，最後造成所有的Mysql從庫負載迅速上升。由於沒辦法在短期內增加讀的伺服器，所以採取對Mysql進行了一些配置，以犧牲資料即時性為代價，來換取所有伺服器的生命安全。呵呵，具體相關調整以及思路如下：

MyISAM在讀操作佔主導的情況下是很高效的。可一旦出現大量的讀寫並發，同InnoDB相比，MyISAM的效率就會直線下降，而且，MyISAM和
InnoDB的資料存放區方式也有顯著不同：通常，在MyISAM裡，新資料會被附加到資料檔案的結尾，可如果時常做一些UPDATE，DELETE操作之
後，資料檔案就不再是連續的，形象一點來說，就是資料檔案裡出現了很多洞洞，此時再插入新資料時，按預設設定會先看這些洞洞的大小是否可以容納下新資料，
如果可以，則直接把新資料儲存到洞洞裡，反之，則把新資料儲存到資料檔案的結尾。之所以這樣做是為了減少資料檔案的大小，降低檔案片段的產生。但
InnoDB裡則不是這樣，在InnoDB裡，由於主鍵是cluster的，所以，資料檔案始終是按照主鍵排序的，如果使用自增ID做主鍵，則新資料始終
是位於資料檔案的結尾。

瞭解了這些基礎知識，下面說說MyISAM幾個容易忽視的配置選項：

concurrent_insert：

通常來說，在MyISAM裡讀寫操作是串列的，但當對同一個表進行查詢和插入操作時，為了降低鎖競爭的頻率，根據concurrent_insert的設定，MyISAM是可以平行處理查詢和插入的：

當concurrent_insert=0時，不允許並發插入功能。

當concurrent_insert=1時，允許對沒有洞洞的表使用並發插入，新資料位元於資料檔案結尾（預設）。

當concurrent_insert=2時，不管表有沒有洞洞，都允許在資料檔案結尾並發插入。

這樣看來，把concurrent_insert設定為2是很划算的，至於由此產生的檔案片段，可以定期使用OPTIMIZE
TABLE文法最佳化。

max_write_lock_count：

預設情況下，寫操作的優先順序要高於讀操作的優先順序，即便是先發送的讀請求，後發送的寫請求，此時也會優先處理寫請求，然後再處理讀請求。這就造成一個問題：一旦我發出若干個寫請求，就會堵塞所有的讀請求，直到寫請求全都處理完，才有機會處理讀請求。此時可以考慮使用max_write_lock_count：

max_write_lock_count=1

有了這樣的設定，當系統處理一個寫操作後，就會暫停寫操作，給讀操作執行的機會。

low-priority-updates：

我們還可以更乾脆點，直接降低寫操作的優先順序，給讀操作更高的優先順序。

low-priority-updates=1

綜合來看，concurrent_insert=2是絕對推薦的，至於max_write_lock_count=1和low-priority-updates=1，則視情況而定，如果可以降低寫操作的優先順序，則使用low-priority-updates=1，否則使用max_write_lock_count=1。