MYSQL的發(fā)生死鎖比別的數(shù)據(jù)庫(kù)少的原因

本篇內(nèi)容介紹了“MYSQL的發(fā)生死鎖比別的數(shù)據(jù)庫(kù)少的原因”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

主要的原因有幾點(diǎn)

1  傳統(tǒng)的系統(tǒng)的設(shè)計(jì)基本上是圍繞著一個(gè)或幾個(gè)核心表進(jìn)行的查詢和DML 操作完成的，而一般傳統(tǒng)的系統(tǒng)在設(shè)計(jì)之初可能由于業(yè)務(wù)大小，和業(yè)務(wù)量上，開(kāi)發(fā)設(shè)計(jì)核心表的初衷都比較簡(jiǎn)單，但隨著業(yè)務(wù)的復(fù)雜度，或業(yè)務(wù)量的上漲，原先的核心表的設(shè)計(jì)就會(huì)產(chǎn)生瓶頸，試想如果是一個(gè)公司的核心人員，原理只負(fù)責(zé) A 業(yè)務(wù)，后續(xù)由于業(yè)務(wù)擴(kuò)展 B ,C ,D 業(yè)務(wù)都需要他來(lái)復(fù)制，并且還有是不是其他業(yè)務(wù)需要他來(lái)協(xié)調(diào)，或者詢問(wèn)他的開(kāi)發(fā)，他在厲害，在同一個(gè)時(shí)刻也只能處理一個(gè)事件。其他的事件都的在wait的狀態(tài)，而如果兩個(gè)任務(wù)或多個(gè)任務(wù)同時(shí)都需要 他，則這幾個(gè)事務(wù)就的打起來(lái)，最后誰(shuí)更重要就占用這個(gè)核心的人員。

所以在系統(tǒng)的設(shè)計(jì)中，隨著業(yè)務(wù)的擴(kuò)展，可能就需要給這個(gè)核心的人員，找一個(gè)幫手，或者直接將他的功能分解， 必須我們可以給個(gè)核心的人員，找一個(gè)幫手。

說(shuō)起來(lái)容易，做起來(lái)難，面臨的第一個(gè)問(wèn)題就是，核心表如果功能有重合的部分，則字段也有重合的地方，如何在一次輸入將部分相同的數(shù)據(jù)放入到兩張表或多張表，這是一個(gè)問(wèn)題，是通過(guò)程序來(lái)做，還是通過(guò)其他的方式進(jìn)行傳遞，如果是通過(guò)程序來(lái)做，將其變成一個(gè)事務(wù)好，還是通過(guò)類似MQ 的消息傳遞的方式好，或者用第三方的數(shù)據(jù)庫(kù)表復(fù)制的方式。

所以一個(gè)系統(tǒng)隨著越來(lái)越復(fù)雜，考驗(yàn)表設(shè)計(jì)人員，或者BDER的事情就多起來(lái)，這時(shí)如果DBER 還是重基礎(chǔ)數(shù)據(jù)庫(kù)知識(shí)，而沒(méi)有業(yè)務(wù)或其他更廣泛的知識(shí)，則你也只能聽(tīng)命于他人，起不到自己應(yīng)該有的作用。

反過(guò)來(lái)，題目中為什么提到MYSQL的死鎖少的問(wèn)題

1  一般來(lái)說(shuō)用MYSQL的企業(yè)大部分都是互聯(lián)網(wǎng)企業(yè)，而互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)相對(duì)傳統(tǒng)行業(yè)，業(yè)務(wù)簡(jiǎn)單，并且互聯(lián)網(wǎng)企業(yè)的技術(shù)人員的水平，相對(duì)傳統(tǒng)企業(yè)來(lái)說(shuō)要高。

2  用到MYSQL的企業(yè)部分核心的業(yè)務(wù)都在分庫(kù)，或分表，通過(guò)分庫(kù)和分表可以將這類問(wèn)題進(jìn)行一定的化解，降低表在提供信息時(shí)的耦合度，其實(shí)還是那句話，空間換了時(shí)間。

3  使用MYSQL  的系統(tǒng)大部分也在使用讀寫(xiě)分離，這樣的使用也有利于化解查詢和DML 操作之間的問(wèn)題，而死鎖大部分的問(wèn)題產(chǎn)生于這方面的影響。

所以這也是上面某些群里面的人員，提到了MYSQL的死鎖為什么相對(duì)于其他數(shù)據(jù)庫(kù)系統(tǒng)少的主要原因。

其實(shí)還有一個(gè)原因，有些互聯(lián)網(wǎng)企業(yè)的DML 操作，不是通過(guò)簡(jiǎn)單的條件進(jìn)行的DML ，而是根據(jù)主鍵進(jìn)行DML 操作，在DML 操作之前要獲取需要DML操作的主鍵，而在MYSQL的主鍵操作是很快的，具體原理這里也就不再提了，以免婆婆媽媽。

而其他數(shù)據(jù)庫(kù)系統(tǒng)是否也可以，回答是，是的。

SQL SERVER Always on 是可以進(jìn)行讀寫(xiě)分離的，而 PG 更是天生就有這樣的基因，各種數(shù)據(jù)的復(fù)制技術(shù)都是有的，基本上用在MYSQL上的技術(shù)在PG上進(jìn)行讀寫(xiě)分離都是OK 的。 

這里不提ORACLE的原因，有2 ， 1 ORACLE 在buffer 內(nèi)存設(shè)計(jì)上異同于其他數(shù)據(jù)庫(kù)，2 使用ORACLE的數(shù)據(jù)庫(kù)的表設(shè)計(jì)人員，比較傳統(tǒng)，出現(xiàn)上邊死鎖的設(shè)計(jì)方式與傳統(tǒng)的三范式以及傳統(tǒng)的表設(shè)計(jì)方式有關(guān)，并且什么讀寫(xiě)分離，主鍵操作，在ORACLE上都不大現(xiàn)實(shí)。因?yàn)镺RACLE 這個(gè)數(shù)據(jù)庫(kù)本身的設(shè)計(jì)思路就是單體擴(kuò)容的思路，這本身就是造成瓶頸的原因。

其實(shí)討論到表設(shè)計(jì)這個(gè)事情來(lái)說(shuō)，一般初期是不會(huì)考慮的特別周到的，1 業(yè)務(wù)量，業(yè)務(wù)的清晰度，可能都達(dá)不到一個(gè)設(shè)計(jì)之初需要進(jìn)行考慮的需求，2 本身非MYSQL的數(shù)據(jù)庫(kù)功能上都能容納一些不合理的設(shè)計(jì)和查詢。

而正是因?yàn)檫@樣，其他的數(shù)據(jù)庫(kù)使用中隨著時(shí)間的流逝，和業(yè)務(wù)的擴(kuò)展，發(fā)生問(wèn)題的幾率都比 使用MYSQL的數(shù)據(jù)庫(kù)的大。

終其原因，如果混亂的，不合理的使用MYSQL數(shù)據(jù)庫(kù)，則還沒(méi)到死鎖爆發(fā)，數(shù)據(jù)庫(kù)早就不干活了。

“MYSQL的發(fā)生死鎖比別的數(shù)據(jù)庫(kù)少的原因”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！