記一次MySql鎖知識

                                      生活是不是一直都是這麼難?

 

說起鎖這個概念,估計我們都不會很陌生吧。在學習Java線程那塊的時候,我相信我們或多或少的都有接觸過鎖這個概念,也許沒有很深的感覺,如果我說 synchronized 的話,那麼打架肯定不陌生了吧,就是在多個線程競爭同一個共享資源或者對全局變量進行操作的時候就會用 synchronized 。MySql中也是有鎖這個概念的,目的和代碼中的,個人認爲也是大致相同的,肯定防止同一個資源在同一時間被多個線程修改啥的等等啊。

 

MySql 鎖 : 定義

   鎖是計算機協調多個進程或線程併發訪問某一資源的機制。

   在數據庫中,除傳統的計算資源(如CPU、RAM、I/O等)的爭用以外,數據也是一種供許多用戶共享的資源。如何保證數據併發訪問的一致性、有效性是所有數據庫必須解決的一個問題,鎖衝突也是影響數據庫併發訪問性能的一個重要因素。從這個角度來說,鎖對數據庫而言顯得尤其重要,也更加複雜。

 

對數據操作的類型

  讀鎖 : 針對同一份數據,多個讀操作可以同時進行而不會互相影響。(共享鎖)

  寫鎖 : 當前寫操作沒有完成前,它會阻斷其他寫鎖和讀鎖。 (獨佔鎖,也叫排它鎖)

  共享鎖和獨佔鎖可以從字面意思上簡單理解爲 : 共享可以有多個線程一起操作,獨佔就只有一個線程可以操作.

 

   表鎖 : 簡單的理解爲鎖住一個表

   行鎖 : 簡單的理解爲鎖住表中的一行

   表鎖和行鎖的區別 : 可想而知。一個是鎖着了表,就是你其他的線程對這個表操作不了。一個是鎖住了表中的某一行,但是你其他的線程還是能訪問表中除了這一行的其他行。

  

 

  InnoDB與MyISAM 和 事務

InnoDB : 一是支持事務(TRANSACTION);二是採用了行級鎖

事務是由一組SQL語句組成的邏輯處理單元,事務具有以下4個屬性,通常簡稱爲事務的ACID屬性:

  •   原子性(Atomicity):事務是一個原子操作單元,其對數據的修改,要麼全都執行,要麼全都不執行。
  • 一致性(Consistent):在事務開始和完成時,數據都必須保持一致狀態。這意味着所有相關的數據規則都必須應用於事務的修改,以保持數據的完整性;事務結束時,所有的內部數據結構(如B樹索引或雙向鏈表)也都必須是正確的。

  • 隔離性(Isolation):數據庫系統提供一定的隔離機制,保證事務在不受外部併發操作影響的“獨立”環境執行。這意味着事務處理過程中的中間狀態對外部是不可見的,反之亦然。

  • 持久性(Durable):事務完成之後,它對於數據的修改是永久性的,即使出現系統故障也能夠保持。

 

併發事務帶來處理帶來的問題 :

  • 更新丟失 : 當兩個或多個事務選擇同一行,然後基於最初選定的值更新該行時,由於每個事務都不知道其他事務的存在,就會發生丟失更新問題--最後的更新覆蓋了由其他事務所做的更新。

    例如,兩個程序員修改同一java文件。每程序員獨立地更改其副本,然後保存更改後的副本,這樣就覆蓋了原始文檔。最後保存其更改副本的編輯人員覆蓋前一個程序員所做的更改。如果在一個程序員完成並提交事務之前,另一個程序員不能訪問同一文件,則可避免此問題。

  • 髒讀 :  一個事務正在對一條記錄做修改,在這個事務完成並提交前,這條記錄的數據就處於不一致狀態;這時,另一個事務也來讀取同一條記錄,如果不加控制,第二個事務讀取了這些“髒”數據,並據此做進一步的處理,就會產生未提交的數據依賴關係。這種現象被形象地叫做”髒讀”。 

    一句話:事務A讀取到了事務B已修改但尚未提交的的數據,還在這個數據基礎上做了操作。此時,如果B事務回滾,A讀取

    的數據無效,不符合一致性要求。

  • 不可重複讀 :  在一個事務內,多次讀同一個數據。在這個事務還沒有結束時,另一個事務也訪問該同一數據。那麼,在第一個事務的兩次讀數據之間。由於第二個事務的修改,那麼第一個事務讀到的數據可能不一樣,這樣就發生了在一個事務內兩次讀到的數據是不一樣的,因此稱爲不可重複讀,即原始讀取不可重複。

      一句話:一個事務範圍內兩個相同的查詢卻返回了不同數據。

  • 幻讀 :  一個事務按相同的查詢條件重新讀取以前檢索過的數據,卻發現其他事務插入了滿足其查詢條件的新數據,這種現象就稱爲“幻讀”。

    一句話:事務A讀取到了事務B提交的新增數據,不符合隔離性

 

 建議

  •   Innodb存儲引擎由於實現了行級鎖定,雖然在鎖定機制的實現方面所帶來的性能損耗可能比表級鎖定會要更高一些,但是在整體併發處理能力方面要遠遠優於MyISAM的表級鎖定的。當系統併發量較高的時候,Innodb的整體性能和MyISAM相比就會有比較明顯的優勢了。

      但是,Innodb的行級鎖定同樣也有其脆弱的一面,當我們使用不當的時候,可能會讓Innodb的整體性能表現不僅不能比MyISAM高,甚至可能會更差。

  • 儘可能讓所有數據檢索都通過索引來完成,避免無索引行鎖升級爲表鎖。

  • 儘可能較少檢索條件,避免間隙鎖

  • 儘量控制事務大小,減少鎖定資源量和時間長度

  • 鎖住某行後,儘量不要去調別的行或表,趕緊處理被鎖住的行然後釋放掉鎖。

  • 涉及相同表的事務,對於調用表的順序儘量保持一致。

  • 在業務環境允許的情況下,儘可能低級別事務隔離

 

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章