MySQL鎖和隔離機制

一：MySQL鎖

二：MySQL事務

三：MySQL隔離級別

四：MVCC

1.1爲何要有鎖？

    由於數據庫要解決併發控制問題。在同一時刻，可能會有多個客戶端對某張表的某條數據或某些數據進行操做，好比有的在讀取該行數據，其餘的嘗試去刪除它。爲了保證數據的一致性，數據庫就要對這種併發操做進行控制，所以就有了鎖的概念。

1.2鎖的分類

    1.2.1按對數據的操做類型

        LOCK TABLES tb_namelock_type{READ|WRITE};

        UNLOCKTABLES ;

        讀鎖（共享鎖）：針對同一塊數據，多個讀操做能夠同時進行而不會互相影響。

                        寫鎖（排它鎖）：當前寫操做沒有完成前，它會阻斷其餘寫鎖和讀鎖。

   

        示例1：讀鎖

            

            

            

            

        示例2：寫鎖

              

              

              

              

    

    1.2.2鎖的粒度：MySQL服務器僅支持表級別的所，行所須要存儲引擎完成

        表鎖：管理鎖的開銷最小，同時容許的併發量也最小的鎖機制。MyIsam存儲引擎使用的鎖機制。當要寫入數據時，把整個表都鎖上，此時其餘讀、寫動做一概等待。在MySql中，除了MyIsam存儲引擎使用這種鎖策略外，MySql自己也使用表鎖來執行某些特定動做，好比alter table.

 

        行鎖：能夠支持最大併發的鎖策略。InnoDB存儲引擎採用這種策略

2.1 ACID

    原子性（Autmic）：事務所引發的數據庫操做，要麼都完成，要麼都不執行

        

    一致性（Consistency）：完成以前和完成以後是同樣的（兩個賬戶的錢，轉帳以前和以後的總和是同樣的）

        

    隔離性（Isolation）：一個事務的執行不能影響另外一個事務的執行

        

    持久性（Durability）：一旦事務成功完成，系統必須保證任何故障都不能引發事務的不一致性。

2.2事務的狀態

    

2.3保存點（SAVEPOINT）

    一個很大的事務，這個事務有100個操做，執行到80個的時候發現第75個錯了，怎麼辦？

    撤銷？？---->80個都撤銷了--->很差

        

    這樣就引出保存點了，每10個作一次保存點

 

    回滾保存點：ROLLBACK TO sid

    

    示例：

    

    

3.1事務的隔離級別

    READ-UNCOMMITTED：讀未提交  別人一操做，立馬就能看見(最低的隔離級別)

                  

    READ-COMMITTED：讀提交  別人提交了，才能看見

                  

    REPEATABLE-READ：可重讀 

        （無論別的事務是否提交，個人事務以內看到的依然是同樣的，例如A事務執行了UPDATE操    

            做，B事務執行SELECT操做，在A執行前和後,B執行的結果都同樣）

                  

    SERIALIZABLE：可串行化

        

    查看當前數據庫的隔離級別：

        SHOW GLOBAL VARIABLES LIKE '%ISO%';

        SELECT @@TX_ISOLATION;

    

    

3.2事務隔離級別對事務的影響

3.2.1READ-UNCOMMITTED示例

【客戶端1】

【客戶端2】

【客戶端1】

【客戶端2】

總結：客戶端2在一個事務內，兩次讀取的數據不同，產生了幻讀

3.2.2READ-COMMITTED

【客戶端1】

【客戶端2】

【客戶端1】

【客戶端2】

總結：客戶端1未執行提交以前，客戶端2看不到更新後的數據，客戶端1執行提交以後，客戶端2看到了更新之後的數據，客戶端2在一個事務內，執行兩次查詢仍然看到了不一樣的結果，依然存在幻讀的問題

3.2.3REPEATABLE-READ

【客戶端1】

【客戶端2】

【客戶端1】

【客戶端2】

總結：客戶端2在提交前和提交後看到的數據依然不同，產生了幻讀

3.2.4SERIALIZABLE

【客戶端1】

【客戶端2】

【客戶端1】

【客戶端2】

總結：雖然不存在數據幻讀的問題，可是執行效率很是低

如下內容來自於：http://blog.csdn.net/chen77716/article/details/6742128

4.1相關概念

redo log

redo log就是保存執行的SQL語句到一個指定的Log文件，當Mysql執行recovery時從新執行redo log記錄的SQL操做便可。當客戶端執行每條SQL（更新語句）時，redo log會被首先寫入log buffer；當客戶端執行COMMIT命令時，log buffer中的內容會被視狀況刷新到磁盤。redo log在磁盤上做爲一個獨立的文件存在，即Innodb的log文件。

undo log

與redo log相反，undo log是爲回滾而用，具體內容就是copy事務前的數據庫內容（行）到undo buffer，在適合的時間把undo buffer中的內容刷新到磁盤。undo buffer與redo buffer同樣，也是環形緩衝，但當緩衝滿的時候，undo buffer中的內容會也會被刷新到磁盤；與redo log不一樣的是，磁盤上不存在單獨的undo log文件，全部的undo log均存放在主ibd數據文件中（表空間），即便客戶端設置了每表一個數據文件也是如此。

rollback segment

回滾段這個概念來自Oracle的事物模型，在Innodb中，undo log被劃分爲多個段，具體某行的undo log就保存在某個段中，稱爲回滾段。能夠認爲undo log和回滾段是同一意思。

4.2數據的更新過程

初始數據：假設這是剛剛INSERT的數據，能夠認爲隱含ID爲1，其它兩個值爲NULL

事務1：修改NAME和AGE字段的值

Transacation1

事務2：修改NAME和AGE字段的值

Transacation2