innodb引擎支援行級鎖。
鎖實現了事務之間的隔離功能。
悲觀鎖，排他鎖種類：
1. row-level lock 或record lock 都是指的行級鎖
2. gap 間隙鎖
3. next-lock 下鍵鎖
隔離級別（隔離的是資料的讀，預設的級別是rr模式）：也稱讀的隔離性級別
檢視資料庫當前隔離級別：select @@tx_isolation;
1. ru 讀未遞交，出現髒讀. 即讀取到了記憶體髒頁中的資料
2. rc 讀已遞交，出現不可重複讀，也出現了幻讀，隔離了髒讀
3. rr 可重複讀，解決了不可重複讀，利用undo的快照技術；
也會有幻讀，但是利用gap間隙鎖+nextlock下鍵鎖可以解決幻讀現象，
該種級別下（利用的mvcc機制），每開啟一視窗都會有一undo快照，不論其它視窗中如何修改資料，
在當前視窗中查到的資料都不會有任何變化，除非重新登陸。
mvcc多版本控制機制，就是利用undo快照來實現的。
4. se 序列化，可以防止死鎖，但併發事務效能差
配置檔案中設定隔離級別：vim /xx/my.cnf中新增
1. transaction_isolation=read-uncommitted
2. transaction_isolation=read-committed
3. transaction_isolation=repeatable-read
髒讀講解：
發生於ru模式下，即讀取到了記憶體髒頁中的資料，叫髒讀；
不可重複讀講解：
發生於rc模式下，在乙個視窗中不斷的修改資料並遞交，在另乙個視窗中每次查詢都能查到最新的資料值
這種現象叫做不可重複讀。
可重複讀講解：
發生於rr模式下，在乙個視窗中不斷的修改資料並遞交，在另乙個視窗中每次查詢的結果都是最原始的資料
除非另乙個視窗斷開重連（或手動commit下），才能看到修改值。注意前提：登陸好兩個視窗後不要斷開重連。
幻讀講解：
發生於rc和rr模式中，在視窗1中使用範圍修改a列的值，視窗2中又插入了此範圍的資料，且視窗2先於
視窗1遞交事務，當視窗1中的範圍修改執行完成並遞交後，查詢此範圍資料時，會看到a列值不全為修改值，
即看到了視窗2中新插入的資料a列值未被修改。
不可重複讀和幻讀的區別：
不可重複讀表現為某行資料一直在發生變化
幻讀表現為統一修改範圍內列值後對修改期間插入的資料不受影響。
解決幻讀的必備條件（範圍條件比如為id>5的資料）：
1. 處於rr模式；
2. gap間隙鎖和nextlock下鍵鎖不是真正的記錄鎖，不會鎖定資料行，只鎖定索引列。所以必須為索引列
利用gap鎖鎖定現有id>5範圍內一些不連續的間隔，不允許對間隔資料寫入
利用nextlock鎖定大於5範圍內最大值後的資料，不允許寫入大於當前最大id值的資料。
gap和nextlock鎖是在滿足以上2個條件時自動上鎖的，之前在rc模式中視窗2中可毫無阻擋的插入範圍內資料，
現在滿足以上2條件，再插入時會阻塞在原地。
mysql innodb下的共享鎖和排他鎖
什麼是共享鎖，什麼是排他鎖？共享鎖 也叫讀鎖，簡稱s鎖，原理 乙個事務獲取了乙個資料行的共享鎖，其他事務能獲得該行對應的共享鎖，但不能獲得排他鎖，即乙個事務在讀取乙個資料行的時候，其他事務也可以讀，但不能對該資料行進行增刪改。排他鎖 也叫寫鎖，簡稱x鎖，原理 乙個事務獲取了乙個資料行的排他鎖，其他事...
MySQL InnoDB引擎鎖的總結
我們開的的各式各樣系統中，系統執行需要cpu 記憶體 i o 磁碟等等資源。但除了硬資源外，還有最為重要的軟資源 資料。當人們訪問操作我們的系統時，其實歸根是對資料的檢視與生產。那麼對於同乙份資料，如果多個使用者同時對它檢視 修改時會出現什麼問題呢？這必然會帶來競爭，而為了控制併發的讀取 修改資料會...
MySQL InnoDB鎖問題（四）
一 innodb行鎖實現方式。innodb行鎖是通過給索引上的索引項來加鎖實現的，如果沒有索引，innodb將通過隱藏的聚簇索引來對記錄加鎖。innodb行鎖分三種情形。1 record lock 對索引項加鎖。2 grap lock 對索引項之間的 間隙 第一條記錄前的 間隙 或者最後一條記錄後的...