我們知道通過鎖機制可以使得對共享資源進行併發訪問時，能夠提供資料的完整性和一致性。實現事務的隔離性要求，可以使得事務可以併發工作。但是鎖提高了併發的提示，也引發了一些問題。主要有以下三種：
髒讀：在不同的事務下，當前事務可以讀到另外事務未提交的資料，即可以讀到髒資料下面分析一下三種問題。不可重複讀：在乙個事務內，兩次讀到的資料不一樣
丟失更新：乙個事務的更新操作會被另乙個事務的更新操作所覆蓋，從而導致資料的不一致
在討論事務相關問題時，我們一定要謹記大前提，那就是在各種事務隔離級別下。拋開隔離級別談事務問題，純屬扯淡。
在不同的事務下，當前事務可以讀到另外事務未提交的資料，即可以讀到髒資料。何為髒資料？髒資料是指事務對緩衝池中的行記錄的修改，並且還沒有提交。髒讀違反了事務的隔離性要求。
髒讀發生在事務隔離級別是read uncommited條件下。而目前絕大多數的資料庫的事務隔離級別都至少設定成了read commited。所以髒讀在生產環境中不常發生。
在乙個事務a內，我們可能會多次讀取同一資料。在這個事務沒有提交之前，可能有其他事務b對資料進行了操作，並且提交了。當事務a再次讀取這份資料時，發現兩次讀到的資料是不一致的，這種情況即為不可重複讀。
不可重複讀和髒讀的區別：髒讀是讀到未提交的資料，違反了資料庫事務的隔離性，而不可重複讀讀到的卻是已經提交的資料，違反了資料庫事務一致性的要求。一般來說，不可重複讀的問題是可以接受的，因為讀到的是已經提交的資料，本身不會帶來很大問題。因此，很多資料庫廠商（如oracle、microsoft sql server）將其資料庫事務的預設隔離級別設定為read commited，在這種隔離級別下允許不可重複讀的現象。
在innodb儲存引擎中，預設的隔離級別是rr，通過使用next-key lock演算法避免了不可重複讀的問題。在next-key lock演算法下，對於索引的掃瞄，不僅是鎖住掃瞄到的索引，而且還鎖住這些索引覆蓋的範圍。因此在這個範圍內的插入都是不允許的，這樣就避免了其他事務在這個範圍內插入資料而導致的不可重複讀問題。
舉例：
事務a事務b
begin
begin
select * from books.stu;//返回6行
insert into book.stu select 7,『lujie』;
commit;
select * from books.stu; //返回7行
MySql儲存引擎InnoDB的鎖
innodb實現了以下兩種型別的行鎖 共享鎖 s 允許乙個事務去讀一行，阻止其他事務獲得相同的資料集的排他鎖。排他鎖 x 允許獲得排他鎖的事務更新資料，阻止其他事務獲得相同資料集的共享鎖和排他鎖。共享鎖就是我讀的時候，你可以讀，但是不能寫。排他鎖就是我寫的時候，你不能讀也不能寫。另外，為了允許行鎖和...
Innodb儲存引擎的鎖機制（一）
隔離級別到底如何實現的呢？鎖 mvcc 鎖是用於管理不同事務對共享資源的併發訪問 表鎖與行鎖的區別 鎖定粒度 表鎖 行鎖 加鎖效率 表鎖 行鎖 衝突概率 表鎖 行鎖 併發效能 表鎖 行鎖 innodb儲存引擎支援行鎖和表鎖 另類的行鎖 行鎖的演算法 users表的id和idcode和name列是索引...
MySQL鎖之 InnoDB儲存引擎及其鎖機制
首先要解決的乙個誤區就是 innodb儲存引擎是基於事務的。而前面博文所講的myisam儲存引擎是不支援事務的。那麼什麼是基於事務的呢？複製過來一段我覺得講得還不錯的話 在預設的情況下，mysql 從自動提交 autocommit 模式執行，這種模式會在每條語句執行完畢後把它作出的修改立刻提交給資料...