MYSQL事務

事務：

• 原子性 ： 要麼都執行，要麼都不執行。

• 一致性： 結果要麼都成功 ，要麼都失敗。

• 隔離性： 事務之間是互不干擾的

• 永續性： 事務一旦被提交，對資料庫的改變是永久性的。

   

事務的隔離級別：

• 未提交讀: 髒讀

  • 一個事務讀取了別的事務修改了但未提交的資料

• 提交讀：不可重複讀

  • 同一個事務讀取到的資料不同 ，可能是被別的事務把資料修改了

• 可重複讀：幻讀 (mysql預設的事務隔離級別)

  • 分配一個版本號 ，只讀這一個版本號 ，解決了提交讀的問題 但可能讀取到的資料跟庫裡面不一致

• 可序列讀

  • 事務的最高隔離級別，強制事務排序 ，加共享鎖

  • 可以解決髒讀、不可重複讀、幻讀問題，但會導致大量的超時和鎖競爭關係，一般不推薦使用

mysql中的鎖

MyISAM和InnoDB支援的鎖型別**(mysql的兩種最常用資料庫引擎)

樂觀鎖悲觀鎖作用

•  在併發訪問情況下，很有可能出現不可重複讀等等讀現象。

• 為了更好的應對高併發，封鎖、時間戳、樂觀併發控制(樂觀鎖)、  悲觀併發控制(悲觀鎖)都是併發控制採用的主要技術方式。

悲觀鎖(讀取資料就加鎖)

• 總是假設最壞的情況，每次去讀資料的時候都認為別人會修改，所以每次讀取資料的時候就加上一把鎖

  在讀取之前就加鎖，期間其他使用者阻塞等待訪問該記錄。

樂觀鎖(讀取資料不加鎖，修改資料加鎖)

• 總是假設最好的情況，每次去讀資料的時候認為別人不會修改，所以每次讀取資料的時候不用加鎖

  在更新資料在加一把鎖

• 在更新資料的時候需要比較程式中的庫存量與資料庫中的庫存量是否相等，如果相等則進行更新

  反之程式重新獲取庫存量，再次進行比較，直到兩個庫存量的數值相等才進行資料更新。

使用場景

• 樂觀鎖適用於寫比較少的情況下（多讀場景），即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。

• 悲觀鎖適用於讀比較少的情況下（多寫場景），如果是多寫的情況，一般會經常產生衝突，這就會導致上層應用會不斷的進行retry，這樣反倒是降低了效能，所以一般多寫的場景下用悲觀鎖就比較合適。

共享鎖

• 共享鎖又叫讀鎖，如果事務T對A加上共享鎖，則其它事務只能對A再加共享鎖，不能加其它鎖。

• 獲准共享鎖的事務只能讀資料，不能寫資料。

排它鎖

• 排它鎖又叫寫鎖，如果事務T對A加上排它鎖，則其它事務都不能對A加任何型別的鎖。獲准排它鎖的事務既能讀資料，又能寫資料。

&n