myisam和innodb的區(qū)別

myisam讀的效果好,寫的效率差,這和它數(shù)據(jù)存儲(chǔ)格式,索引的指針和鎖的策略有關(guān)的,它的數(shù)據(jù)是順序存儲(chǔ)的(innodb數(shù)據(jù)存儲(chǔ)方式是聚簇索引),他的索引btree上的節(jié)點(diǎn)是一個(gè)指向數(shù)據(jù)物理位置的指針,所以查找起來很快,(innodb索引節(jié)點(diǎn)存的則是數(shù)據(jù)的主鍵,所以需要根據(jù)主鍵二次查找);myisam鎖是表鎖,只有讀讀之間是并發(fā)的,寫寫之間和讀寫之間(讀和插入之間是可以并發(fā)的,去設(shè)置concurrent_insert參數(shù),定期執(zhí)行表優(yōu)化操作,更新操作就沒有辦法了)是串行的,所以寫起來慢,并且默認(rèn)的寫優(yōu)先級比讀優(yōu)先級高,高到寫操作來了后,可以馬上插入到讀操作前面去,如果批量寫,會(huì)導(dǎo)致讀請求餓死,所以要設(shè)置讀寫優(yōu)先級或設(shè)置多少寫操作后執(zhí)行讀操作的策略;myisam不要使用查詢時(shí)間太長的sql,如果策略使用不當(dāng),也會(huì)導(dǎo)致寫?zhàn)I死,所以盡量去拆分查詢效率低的sql

innodb一般都是行鎖,這個(gè)一般指的是sql用到索引的時(shí)候,行鎖是加在索引上的,不是加在數(shù)據(jù)記錄上的,如果sql沒有用到索引,仍然會(huì)鎖定表,mysql的讀寫之間是可以并發(fā)的,普通的select是不需要鎖的,當(dāng)查詢的記錄遇到鎖時(shí),用的是一致性的非鎖定快照讀,也就是根據(jù)數(shù)據(jù)庫隔離級別策略,會(huì)去讀被鎖定行的快照,其它更新或加鎖讀語句用的是當(dāng)前讀,讀取原始行;因?yàn)槠胀ㄗx與寫不沖突,所以innodb不會(huì)出現(xiàn)讀寫?zhàn)I死的情況,又因?yàn)樵谑褂盟饕臅r(shí)候用的是行鎖,鎖的粒度小,競爭相同鎖的情況就少,就增加了并發(fā)處理,所以并發(fā)讀寫的效率還是很優(yōu)秀的,問題在于索引查詢后的根據(jù)主鍵的二次查找導(dǎo)致效率低;ps:很奇怪,為什innodb的索引葉子節(jié)點(diǎn)存的是主鍵而不是像mysism一樣存數(shù)據(jù)的物理地址指針嗎?如果存的是物理地址指針不就不需要二次查找了嗎,這也是我開始的疑惑,根據(jù)mysism和innodb數(shù)據(jù)存儲(chǔ)方式的差異去想,你就會(huì)明白了,我就不費(fèi)口舌了!所以innodb為了避免二次查找可以使用索引覆蓋技術(shù),無法使用索引覆蓋的,再延伸一下就是基于索引覆蓋實(shí)現(xiàn)延遲關(guān)聯(lián)

參考

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容