快捷導(dǎo)航

Mysql(MyISAM)的讀寫(xiě)互斥鎖問(wèn)題的解決方法

更新時(shí)間：2011年09月27日 00:32:11 作者：

最近因?yàn)閿?shù)據(jù)庫(kù)讀的請(qǐng)求增加，出現(xiàn)了比較嚴(yán)重的讀寫(xiě)鎖問(wèn)題，由于主從分離，主服務(wù)器很快的執(zhí)行完了寫(xiě)入的操作，但從庫(kù)由于有大量的select的查詢，會(huì)被這些來(lái)自主輔同步的update,insert嚴(yán)重堵塞，最后造成所有的Mysql從庫(kù)負(fù)載迅速上升。

由于沒(méi)辦法在短期內(nèi)增加讀的服務(wù)器，所以采取對(duì)Mysql進(jìn)行了一些配置，以犧牲數(shù)據(jù)實(shí)時(shí)性為代價(jià)，來(lái)?yè)Q取所有服務(wù)器的生命安全。呵呵，具體相關(guān)調(diào)整以及思路如下：

MyISAM在讀操作占主導(dǎo)的情況下是很高效的?？梢坏┏霈F(xiàn)大量的讀寫(xiě)并發(fā)，同InnoDB相比，MyISAM的效率就會(huì)直線下降，而且，MyISAM和 InnoDB的數(shù)據(jù)存儲(chǔ)方式也有顯著不同：通常，在MyISAM里，新數(shù)據(jù)會(huì)被附加到數(shù)據(jù)文件的結(jié)尾，可如果時(shí)常做一些UPDATE，DELETE操作之后，數(shù)據(jù)文件就不再是連續(xù)的，形象一點(diǎn)來(lái)說(shuō)，就是數(shù)據(jù)文件里出現(xiàn)了很多洞洞，此時(shí)再插入新數(shù)據(jù)時(shí)，按缺省設(shè)置會(huì)先看這些洞洞的大小是否可以容納下新數(shù)據(jù)，如果可以，則直接把新數(shù)據(jù)保存到洞洞里，反之，則把新數(shù)據(jù)保存到數(shù)據(jù)文件的結(jié)尾。之所以這樣做是為了減少數(shù)據(jù)文件的大小，降低文件碎片的產(chǎn)生。但 InnoDB里則不是這樣，在InnoDB里，由于主鍵是cluster的，所以，數(shù)據(jù)文件始終是按照主鍵排序的，如果使用自增ID做主鍵，則新數(shù)據(jù)始終是位于數(shù)據(jù)文件的結(jié)尾。

了解了這些基礎(chǔ)知識(shí)，下面說(shuō)說(shuō)MyISAM幾個(gè)容易忽視的配置選項(xiàng)：

concurrent_insert：

通常來(lái)說(shuō)，在MyISAM里讀寫(xiě)操作是串行的，但當(dāng)對(duì)同一個(gè)表進(jìn)行查詢和插入操作時(shí)，為了降低鎖競(jìng)爭(zhēng)的頻率，根據(jù)concurrent_insert的設(shè)置，MyISAM是可以并行處理查詢和插入的：

當(dāng)concurrent_insert=0時(shí)，不允許并發(fā)插入功能。

當(dāng)concurrent_insert=1時(shí)，允許對(duì)沒(méi)有洞洞的表使用并發(fā)插入，新數(shù)據(jù)位于數(shù)據(jù)文件結(jié)尾（缺省）。

當(dāng)concurrent_insert=2時(shí)，不管表有沒(méi)有洞洞，都允許在數(shù)據(jù)文件結(jié)尾并發(fā)插入。

這樣看來(lái)，把concurrent_insert設(shè)置為2是很劃算的，至于由此產(chǎn)生的文件碎片，可以定期使用OPTIMIZE TABLE語(yǔ)法優(yōu)化。

max_write_lock_count：

缺省情況下，寫(xiě)操作的優(yōu)先級(jí)要高于讀操作的優(yōu)先級(jí)，即便是先發(fā)送的讀請(qǐng)求，后發(fā)送的寫(xiě)請(qǐng)求，此時(shí)也會(huì)優(yōu)先處理寫(xiě)請(qǐng)求，然后再處理讀請(qǐng)求。這就造成一個(gè)問(wèn)題：一旦我發(fā)出若干個(gè)寫(xiě)請(qǐng)求，就會(huì)堵塞所有的讀請(qǐng)求，直到寫(xiě)請(qǐng)求全都處理完，才有機(jī)會(huì)處理讀請(qǐng)求。此時(shí)可以考慮使用max_write_lock_count：

max_write_lock_count=1

有了這樣的設(shè)置，當(dāng)系統(tǒng)處理一個(gè)寫(xiě)操作后，就會(huì)暫停寫(xiě)操作，給讀操作執(zhí)行的機(jī)會(huì)。

low-priority-updates：

我們還可以更干脆點(diǎn)，直接降低寫(xiě)操作的優(yōu)先級(jí)，給讀操作更高的優(yōu)先級(jí)。

low-priority-updates=1

綜合來(lái)看，concurrent_insert=2是絕對(duì)推薦的，至于max_write_lock_count=1和low-priority-updates=1，則視情況而定，如果可以降低寫(xiě)操作的優(yōu)先級(jí)，則使用low-priority-updates=1，否則使用max_write_lock_count=1。

您可能感興趣的文章: