Mysql(MyISAM)的讀寫互斥鎖問題的解決方法
更新時間:2011年09月27日 00:32:11 作者:
最近因為數(shù)據(jù)庫讀的請求增加,出現(xiàn)了比較嚴重的讀寫鎖問題,由于主從分離,主服務器很快的執(zhí)行完了寫入的操作,但從庫由于有大量的select的查詢,會被這些來自主輔同步的update,insert嚴重堵塞,最后造成所有的Mysql從庫負載迅速上升。
由于沒辦法在短期內(nèi)增加讀的服務器,所以采取對Mysql進行了一些配置,以犧牲數(shù)據(jù)實時性為代價,來換取所有服務器的生命安全。呵呵,具體相關調(diào)整以及思路如下:
MyISAM在讀操作占主導的情況下是很高效的。可一旦出現(xiàn)大量的讀寫并發(fā),同InnoDB相比,MyISAM的效率就會直線下降,而且,MyISAM和 InnoDB的數(shù)據(jù)存儲方式也有顯著不同:通常,在MyISAM里,新數(shù)據(jù)會被附加到數(shù)據(jù)文件的結(jié)尾,可如果時常做一些UPDATE,DELETE操作之后,數(shù)據(jù)文件就不再是連續(xù)的,形象一點來說,就是數(shù)據(jù)文件里出現(xiàn)了很多洞洞,此時再插入新數(shù)據(jù)時,按缺省設置會先看這些洞洞的大小是否可以容納下新數(shù)據(jù),如果可以,則直接把新數(shù)據(jù)保存到洞洞里,反之,則把新數(shù)據(jù)保存到數(shù)據(jù)文件的結(jié)尾。之所以這樣做是為了減少數(shù)據(jù)文件的大小,降低文件碎片的產(chǎn)生。但 InnoDB里則不是這樣,在InnoDB里,由于主鍵是cluster的,所以,數(shù)據(jù)文件始終是按照主鍵排序的,如果使用自增ID做主鍵,則新數(shù)據(jù)始終是位于數(shù)據(jù)文件的結(jié)尾。
了解了這些基礎知識,下面說說MyISAM幾個容易忽視的配置選項:
concurrent_insert:
通常來說,在MyISAM里讀寫操作是串行的,但當對同一個表進行查詢和插入操作時,為了降低鎖競爭的頻率,根據(jù)concurrent_insert的設置,MyISAM是可以并行處理查詢和插入的:
當concurrent_insert=0時,不允許并發(fā)插入功能。
當concurrent_insert=1時,允許對沒有洞洞的表使用并發(fā)插入,新數(shù)據(jù)位于數(shù)據(jù)文件結(jié)尾(缺?。?。
當concurrent_insert=2時,不管表有沒有洞洞,都允許在數(shù)據(jù)文件結(jié)尾并發(fā)插入。
這樣看來,把concurrent_insert設置為2是很劃算的,至于由此產(chǎn)生的文件碎片,可以定期使用OPTIMIZE TABLE語法優(yōu)化。
max_write_lock_count:
缺省情況下,寫操作的優(yōu)先級要高于讀操作的優(yōu)先級,即便是先發(fā)送的讀請求,后發(fā)送的寫請求,此時也會優(yōu)先處理寫請求,然后再處理讀請求。這就造成一個問題:一旦我發(fā)出若干個寫請求,就會堵塞所有的讀請求,直到寫請求全都處理完,才有機會處理讀請求。此時可以考慮使用max_write_lock_count:
max_write_lock_count=1
有了這樣的設置,當系統(tǒng)處理一個寫操作后,就會暫停寫操作,給讀操作執(zhí)行的機會。
low-priority-updates:
我們還可以更干脆點,直接降低寫操作的優(yōu)先級,給讀操作更高的優(yōu)先級。
low-priority-updates=1
綜合來看,concurrent_insert=2是絕對推薦的,至于max_write_lock_count=1和low-priority-updates=1,則視情況而定,如果可以降低寫操作的優(yōu)先級,則使用low-priority-updates=1,否則使用max_write_lock_count=1。
MyISAM在讀操作占主導的情況下是很高效的。可一旦出現(xiàn)大量的讀寫并發(fā),同InnoDB相比,MyISAM的效率就會直線下降,而且,MyISAM和 InnoDB的數(shù)據(jù)存儲方式也有顯著不同:通常,在MyISAM里,新數(shù)據(jù)會被附加到數(shù)據(jù)文件的結(jié)尾,可如果時常做一些UPDATE,DELETE操作之后,數(shù)據(jù)文件就不再是連續(xù)的,形象一點來說,就是數(shù)據(jù)文件里出現(xiàn)了很多洞洞,此時再插入新數(shù)據(jù)時,按缺省設置會先看這些洞洞的大小是否可以容納下新數(shù)據(jù),如果可以,則直接把新數(shù)據(jù)保存到洞洞里,反之,則把新數(shù)據(jù)保存到數(shù)據(jù)文件的結(jié)尾。之所以這樣做是為了減少數(shù)據(jù)文件的大小,降低文件碎片的產(chǎn)生。但 InnoDB里則不是這樣,在InnoDB里,由于主鍵是cluster的,所以,數(shù)據(jù)文件始終是按照主鍵排序的,如果使用自增ID做主鍵,則新數(shù)據(jù)始終是位于數(shù)據(jù)文件的結(jié)尾。
了解了這些基礎知識,下面說說MyISAM幾個容易忽視的配置選項:
concurrent_insert:
通常來說,在MyISAM里讀寫操作是串行的,但當對同一個表進行查詢和插入操作時,為了降低鎖競爭的頻率,根據(jù)concurrent_insert的設置,MyISAM是可以并行處理查詢和插入的:
當concurrent_insert=0時,不允許并發(fā)插入功能。
當concurrent_insert=1時,允許對沒有洞洞的表使用并發(fā)插入,新數(shù)據(jù)位于數(shù)據(jù)文件結(jié)尾(缺?。?。
當concurrent_insert=2時,不管表有沒有洞洞,都允許在數(shù)據(jù)文件結(jié)尾并發(fā)插入。
這樣看來,把concurrent_insert設置為2是很劃算的,至于由此產(chǎn)生的文件碎片,可以定期使用OPTIMIZE TABLE語法優(yōu)化。
max_write_lock_count:
缺省情況下,寫操作的優(yōu)先級要高于讀操作的優(yōu)先級,即便是先發(fā)送的讀請求,后發(fā)送的寫請求,此時也會優(yōu)先處理寫請求,然后再處理讀請求。這就造成一個問題:一旦我發(fā)出若干個寫請求,就會堵塞所有的讀請求,直到寫請求全都處理完,才有機會處理讀請求。此時可以考慮使用max_write_lock_count:
max_write_lock_count=1
有了這樣的設置,當系統(tǒng)處理一個寫操作后,就會暫停寫操作,給讀操作執(zhí)行的機會。
low-priority-updates:
我們還可以更干脆點,直接降低寫操作的優(yōu)先級,給讀操作更高的優(yōu)先級。
low-priority-updates=1
綜合來看,concurrent_insert=2是絕對推薦的,至于max_write_lock_count=1和low-priority-updates=1,則視情況而定,如果可以降低寫操作的優(yōu)先級,則使用low-priority-updates=1,否則使用max_write_lock_count=1。
相關文章
phpstudy中mysql無法啟動(與本地安裝的mysql沖突)的解決方式
這篇文章主要給大家介紹了關于phpstudy中mysql無法啟動(與本地安裝的mysql沖突)的解決方式,文中通過圖文將解決的方法介紹的非常詳細,需要的朋友可以參考下2022-09-09Mysql學習之數(shù)據(jù)庫檢索語句DQL大全小白篇
這篇文章主要介紹了Mysql數(shù)據(jù)庫檢索語句DQL大全,本文適合數(shù)據(jù)庫初學者,小白也能看懂,有需要的朋友可以收藏閱讀,希望可以有所幫助2021-09-09SQL中current_date()函數(shù)的實現(xiàn)
日期時間類型的數(shù)據(jù)也是經(jīng)常要用到的,SQL中也提供了一些函數(shù)對這些數(shù)據(jù)進行處理,本文主要介紹了SQL中current_date()函數(shù)的實現(xiàn),具有一定的參考價值2024-02-02MySQL 查找價格最高的圖書經(jīng)銷商的幾種SQL語句
不同的圖書,在不同的經(jīng)銷商的價格不同,我們這里要找到每種圖書最高的經(jīng)銷商是誰? 找最低的類似了。2009-07-07pycharm2017實現(xiàn)python3.6與mysql的連接
這篇文章主要為大家詳細介紹了PyCharm連接MySQL數(shù)據(jù)庫的方法,具有一定的參考價值,感興趣的小伙伴們可以參考一下2019-03-03