lock和latch的比較

latch 一般稱為閂鎖(輕量級的鎖) 因為其要求鎖定的時間非常短，若遲勳時間長，則應用效能非常差，在InnoDB儲存引擎中，latch有可以分為mutex(互斥鎖)和rwlock(讀寫鎖)其目的用來保證併發執行緒操作臨界資源的正確性，並且沒有死鎖檢測的機制

lock的物件是事務，用來鎖定的是資料庫中的UI想，如表、頁、行。並且一般lock物件僅在事務commit或rollback後進行釋放(不同事務隔離級別釋放的時間可能不同)，此外lock正如大多數資料庫中一樣，是有死鎖機制的。表顯示了lock與latch的不同

 

Mysql程式碼  

1. mysql> SHOW ENGINE INNODB MUTEX;  
2. +--------+-------------------+-------------+  
3. | Type   | Name              | Status      |  
4. +--------+-------------------+-------------+  
5. | InnoDB | dict0dict.cc:1057 | os_waits=2  |  
6. | InnoDB | log0log.cc:844    | os_waits=1  |  
7. | InnoDB | fil0fil.cc:1690   | os_waits=1  |  
8. | InnoDB | dict0dict.cc:1066 | os_waits=3
     |  
9. | InnoDB | log0log.cc:907    | os_waits=11 |  
10. +--------+-------------------+-------------+  

在DEBUG版本下，通過SHOW ENGINE INNODB MUTEX 可以看到latch的更多資訊

debug中status欄位中的引數介紹

 

若將上鎖的物件看成一棵樹，那麼對最上層的物件上鎖，也就是對最細粒度的物件進行上鎖，那麼首先需要對粗粒度的物件上鎖，如上圖，如果需要對頁上的記錄r進行上X鎖，那麼分別需要對資料A、表、頁上意向鎖IX，最後對記錄r上X鎖,若其中任何一部分導致等待，那麼該操作需要等待粗粒度鎖的完成

 

innodb鎖相關的表

INNODB_LOCKS表

a)        lock_id：鎖的id以及被鎖住的空間id編號、頁數量、行數量

b)        lock_trx_id：鎖的事務id。

c)        lock_mode：鎖的模式。

d)        lock_type：鎖的型別，表鎖還是行鎖

e)        lock_table：要加鎖的表。

f)          lock_index：鎖的索引。

g)        lock_space：innodb儲存引擎表空間的id號碼

h)        lock_page：被鎖住的頁的數量，如果是表鎖，則為null值。

i)          lock_rec：被鎖住的行的數量，如果表鎖，則為null值。

j)          lock_data：被鎖住的行的主鍵值，如果表鎖，則為null值。

innodb_lock_waits表

1)        requesting_trx_id：申請鎖資源的事務id。

2)        requested_lock_id：申請的鎖的id。

3)        blocking_trx_id：阻塞的事務id。

4)        blocking_lock_id：阻塞的鎖的id。

innodb_trx表

trx_id事務ID

trx_state事務狀態

trx_started事務開始時間

trx_requested_lock_idinnodb_locks.lock_id

trx_wait_started事務開始等待的時間

trx_weight

trx_mysql_thread_id事務執行緒ID

trx_query具體SQL語句

trx_operation_state事務當前操作狀態

trx_tables_in_use事務中有多少個表被使用

trx_tables_locked事務擁有多少個鎖

trx_lock_structs

trx_lock_memory_bytes事務鎖住的記憶體大小（B）

trx_rows_locked事務鎖住的行數

trx_rows_modified事務更改的行數

trx_concurrency_tickets事務併發票數

trx_isolation_level事務隔離級別

trx_unique_checks是否唯一性檢查

trx_foreign_key_checks是否外來鍵檢查

trx_last_foreign_key_error最後的外來鍵錯誤

trx_adaptive_hash_latched

trx_adaptive_hash_timeout

一致性非鎖定讀(consistent nonlocking read)是指InnoDB儲存引擎通過多版本控制(multi versionning)的方式來讀取當前執行時間資料庫中行的資料，如果讀取的行正在執行DELETE或UPDATE操作，這是讀取操作不會因此等待行上鎖的釋放。相反的，InnoDB會去讀取行的一個快照資料

 

一致性鎖定讀的SQL語法

Mysql程式碼  

1. -- 排他鎖  
2. SELECT ......  FOR UPDATE  
3. -- 共享鎖  
4. SELECT ...... LOCK IN SHARE MODE  

自增鎖

Mysql程式碼  

1. -- 內部用下列方式實現的  
2. SELECT max(auto_inc_col) FROM t FOR UPDATE;  

MySQL 5.1.22版本開始，InnoDB提供了一種輕量級互斥量的自增長實現機制，這種機制大大提高了自增長插入的效能。

InnoDB提供了一個引數innodb_autoinc_lock_mode來控制自增長的模式，該引數的預設值為1，在繼續討論新的自增長實現方式之前，需要對自增長的插入進行分類

 

引數innodb_autoinc_lock_mode以及各個設定下對自增的影響，其共有3個有效值可以設定 0 1 2 

 

MySql鎖的型別

InnoDB有三種行鎖的演算法：

1，Record Lock：單個行記錄上的鎖。

2，Gap Lock：間隙鎖，鎖定一個範圍，但不包括記錄本身。GAP鎖的目的，是為了防止同一事務的兩次當前讀，出現幻讀的情況。

3，Next-Key Lock：1+2，鎖定一個範圍，並且鎖定記錄本身。對於行的查詢，都是採用該方法，主要目的是解決幻讀的問題。

innodb對於唯一索引，還有主鍵索引使用的是Record Lock，對於普通索引，聯合索引才會使用next key lock演算法，因為唯一索引是一個確定的值，不需要鎖定一個範圍的。

next key lock也可以解決幻讀的問題

MySql中死鎖檢查是通過超時機制，還有 wait-for graph演算法解決的

事務的隔離級別

=================================================================================

 隔離級別            髒讀（Dirty Read）       不可重複讀（NonRepeatable Read）     幻讀（Phantom Read） 

=================================================================================

未提交讀（Read uncommitted）        可能                            可能                       可能

已提交讀（Read committed）          不可能                          可能                        可能

可重複讀（Repeatable read）          不可能                          不可能                     可能

可序列化（Serializable ）                不可能                          不可能                     不可能

================================================================================

·未提交讀(Read Uncommitted)：允許髒讀，也就是可能讀取到其他會話中未提交事務修改的資料

·提交讀(Read Committed)：只能讀取到已經提交的資料。Oracle等多數資料庫預設都是該級別 (不重複讀)

·可重複讀(Repeated Read)：可重複讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB預設級別。在SQL標準中，該隔離級別消除了不可重複讀，但是還存在幻象讀

·序列讀(Serializable)：完全序列化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞

阻塞相關的引數

Mysql程式碼  

1. -- 控制等待的時間，動態引數  
2. innodb_lock_wait_timeout  
3. -- 用來設定是否在等待超時時對進行中的事物進行回滾操作(預設是OFF不回滾)，靜態引數  
4. innodb_rollback_on_timeout  

鎖升級

1.由單獨的SQL在一個物件上持有的鎖數量超過了閥值，之預設值是5000，如果是不同物件則不會升級

2.鎖資源佔用的記憶體超過了啟用記憶體的40%就會發生鎖升級

innodb根據每個事物訪問的每個頁對鎖進行管理，採用的是點陣圖的方式

innodb不存在鎖升級的問題，這些是微軟的SQL存在的

事務的ACID

ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和永續性（durability）。一個很好的事務處理系統，必須具備這些標準特性：

原子性（atomicity）

　　一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性

一致性（consistency）

     資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。（在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會儲存到資料庫中。）

隔離性（isolation）

     通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶彙總程式開始執行，則其看到支票帳戶的餘額並沒有被減去200美元。）

永續性（durability）

　　一旦事務提交，則其所做的修改不會永久儲存到資料庫。（此時即使系統崩潰，修改的資料也不會丟失。永續性是個有佔模糊的概念，因為實際上永續性也分很多不同的級別。有些永續性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的永續性保證的策略。）

事務的分類

扁平事務(Flat Transactions)

帶有儲存點的扁平事務(Flat Transactions with Savepoints)

鏈事務(Chained Transactions)

巢狀事務(Nested Transactions)

分散式事務(Distributed Transactions)

扁平事務 是事務型別中最簡單的一種，但是在實際生產環境中，這可能是使用最頻繁的事務，在扁平事務中，所有操作都處於同一層次，其由BEGIN WORK開始，由COMMIT WORK或ROLLBACK WORK結束，其間的操作是源自的，要麼都執行，要麼都回滾，因此扁平事務是應用程式稱為原子操作的的基本組成模組

帶有儲存點的扁平事務 對於扁平的事務來說，隱式的設定了一個儲存點。然而整個事務中，只有這一個儲存點，因此，回滾只能會滾到事務開始時的狀態，儲存點用SAVE WORK函式來建立，通知系統記錄當前的處理狀態。當出現問題時，儲存點能用作內部的重啟動點，根據應用邏輯，決定是回到最近一個儲存點還是其他更早的儲存點。

 

鏈事務 可視為儲存點模式的一種變種，帶有儲存點的扁平事務，當發生系統崩潰是，所有的的儲存點都將消失，因為其儲存點是易失的，這意味著當進行恢復時，事務需要從開始處重新執行，而不能從最近的一個儲存點繼續執行

鏈事務的思想是：在提交一個事務時，釋放不需要的資料物件，將必要的處理上下文隱式地傳給下一個要開始的事務，提交事務操作和開始下一個事務操作 將合併為一個原子操作，這意味著下一個事務將看到上一個事務的結果，就好像一個事務中進行的一樣，如圖顯示了鏈事務的工作方式

巢狀事務 是一個層次結構框架，由一個頂層事務(top-level transaction)控制著各個層次的事務，頂層事務之下巢狀的事務被稱為子事務，其控制每一個區域性的變換

採用儲存點技術比巢狀查詢有更大的靈活性

但是用儲存點技術來模擬巢狀事務在鎖的持有方面還是與巢狀查詢有些區別。當通過儲存點技術來模擬巢狀事務時，使用者無法選擇哪些鎖需要被子事務整合，哪些需要被父事務保留

 

事務控制語句

Mysql程式碼  

1. start transction 顯示的開啟一個事務  
2. begin   顯示的開啟一個事務  
3.  commit （commit work）  
4.     commit work與completion_type的關係，commit work是用來控制事務結束後的行為，是chain還是release的，可以通過引數completion_type來控制，預設為0  
5. rollback，rollback work與commit，commit work的工作原理一樣。  
6. rollback（rollback work）  
7. savepoint [identifier]  在事務中建立一個儲存點，一個事務允許有多個儲存點  
8. release savepoint [identifier]  刪除事務中的儲存點，當時一個儲存點也沒有時執行這個命令，會報錯丟擲一個異常  

事務操作的統計

因為InnoDB儲存引擎是支援事務的，因此對於InnoDB儲存引擎的應用，在考慮每秒請求數（Question Per Second，QPS）的同時，也許更應該關注每秒事務處理的能力（Transaction Per Second，TPS）。

計算TPS的方法是（com_commit+com_rollback）/time。但是用這種方法計算的前提是：所有的事務必須都是顯式提交的，如果存在隱式的提交和回滾（預設autocommit=1），不會計算到com_commit和com_rollback變數中。

Mysql程式碼  

1. show global status like'com_commit';   
2. show global status like'com_rollback';   

分散式事務

XA 事務的基礎是兩階段提交協議。需要有一個事務協調者來保證所有的事務參與者都完成了準備工作(第一階段)。如果協調者收到所有參與者都準備好的訊息，就會通知所有的事務都可以提交了（第二階段）。MySQL 在這個XA事務中扮演的是參與者的角色，而不是協調者(事務管理器)。

Mysql 的XA事務分為內部XA和外部XA。 外部XA可以參與到外部的分散式事務中，需要應用層介入作為協調者；內部XA事務用於同一例項下跨多引擎事務，由Binlog作為協調者，比如在一個儲存引擎提交時，需要將提交資訊寫入二進位制日誌，這就是一個分散式內部XA事務，只不過二進位制日誌的參與者是MySQL本身。 Mysql 在XA事務中扮演的是一個參與者的角色，而不是協調者。

基本語法

Mysql程式碼  

1. XA {START|BEGIN} xid [JOIN|RESUME]     啟動一個XA事務 (xid 必須是一個唯一值; [JOIN|RESUME]  字句不被支援)      
2. XA END xid [SUSPEND [FOR MIGRATE]]   結束一個XA事務 ( [SUSPEND [FOR MIGRATE]] 字句不被支援)  
3. XA PREPARE xid    準備  
4. XA COMMIT xid [ONE PHASE]    提交XA事務  
5. XA ROLLBACK xid  回滾XA事務  
6. XA RECOVER   檢視處於PREPARE 階段的所有XA事務  

操作演示

Mysql程式碼  

1. mysql> XA START 'xatest';  
2. Query OK, 0 rows affected (0.00 sec)  
3. mysql> INSERT INTO mytable (i) VALUES(10);  
4. Query OK, 1 row affected (0.04 sec)  
5. mysql> XA END 'xatest';  
6. Query OK, 0 rows affected (0.00 sec)  
7. mysql> XA PREPARE 'xatest';  
8. Query OK, 0 rows affected (0.00 sec)  
9. mysql> XA COMMIT 'xatest';  
10. Query OK, 0 rows affected (0.00 sec)  

重做日誌

重做日誌保證了永續性和原子性，鎖用來保持隔離性，undo log則保持了一致性

重做日誌包含重做日誌緩衝(redo log buffer)和重做日誌檔案(redo log file)

為了確保每次日誌都能寫入日誌檔案，在每次將重做日誌緩衝寫入重做日誌檔案後，InnoDB儲存引擎都需要呼叫一次fsync操作，由於重做日誌檔案開啟並沒有使用O_DIRECT選項，因此重做日誌緩衝先寫入檔案系統快取。為了確保重做日誌寫入磁碟，必須進行fsync操作。由於fsync的效率取決於磁碟的效能，因此磁碟的效能決定了事務提交的效能，也就是資料庫的效能

引數innodb_flush_log_at_trx_commit用來控制重做日誌重新整理到磁碟的策略

1 ，表示事務提交時必須呼叫一次fsync操作，

0表示事務提交時不進行寫入重做日誌操作，這個操作僅在master thread中完成，也就是每秒重新整理一次，但可能會出現瞬間宕機資料丟失的可能性

2 表示事務提交時將重做日誌寫入重做日誌檔案，但僅寫入檔案系統的快取中，不進行fsync操作。在這個設定下，當MySQL發生宕機而作業系統不發生宕機時，並不會導致事務的丟失，而當作業系統宕機時，重啟資料庫會丟失未從檔案系統快取重新整理到重做日誌檔案的那部分事務

重做日誌緩衝區和重做日誌組之間的關係

 

在InnoDB儲存引擎中，重做日誌都是以512位元組進行儲存的，這意味著重做日誌快取、重做日誌檔案塊都是以塊block的方式進行儲存的，稱為重做日誌塊(redo log block)每塊的大小512位元組

日誌塊由三部分組成，依次為日誌快頭(log block header)、日誌內容(log body)、日誌塊尾(log block tailer)

 

LOG_BLOCK_HDR_NO用來標記這個陣列中的位置，尤其是遞增並且迴圈使用的。佔用4個位元組。但是由於第一位用來判斷是否是flush bit，所以最大值為2G

LOG_BLOCK_HDR_DATA_LEN佔用2個位元組，表示log block所佔用的大小，當log block被寫滿時，該值為0x200,表示使用全部的log block空間，即佔用512位元組

LOG_BLOCK_FIRST_REC_GROUP 佔用2個位元組，表示log block中第一個日誌所在的偏移量。如果該值的大小和LOG_BLOCK_HDR_DATA_LEN相同，則表示當前log block不包含新的日誌

LOG_BLOCK_CHECKPOINT_NO佔用4位元組，表示該log block最後被寫入時的檢查點第4位元組的值

LOG_BLOCK_TAILER 只由1個部分組成，且值和LOG_BLOCK_HDR_NO相同，並在函式log_block_init中被初始化 LOG_BLOCK_TRL_NO 大小為4位元組

 

重做日誌格式

通用的頭部格式由一下3部分組成

redo_log_type 重做日誌型別

space: 表空間ID

page_no 頁的偏移量

之後是redo log body  

 

body體的內容

 

SHOW ENGINE INNODB STATUS檢視LSN的情況

Mysql程式碼  

1. ---  
2. LOG  
3. ---  
4. Log sequence number 18766833801 -- 表示當前的LSN  
5. Log flushed up to   18766832201 -- 表示重新整理到重做日誌檔案的LSN  
6. Pages flushed up to 18766816420   
7. Last checkpoint at  18766816420 -- 表示重新整理到磁碟的LSN  

由於checkpoint表示已經重新整理到磁碟頁上的LSN，因此在恢復過程中僅需恢復checkpoint開始的日誌部分

 

再放一張完整的log block分析圖

 

undo log

為了滿足事務的原子性，在操作任何資料之前，首先將資料備份到Undo Log，然後進行資料的修改。如果出現了錯誤或者使用者執行了ROLLBACK語句，系統可以利用Undo Log中的備份將資料恢復到事務開始之前的狀態。與redo log不同的是，磁碟上不存在單獨的undo log檔案，它存放在資料庫內部的一個特殊段(segment)中，這稱為undo段(undo segment)，undo段位於共享表空間內。

此外undo log還用來做事務的MMVC功能，多版本併發

undo log不是物理操作，是邏輯的反向操作，比如插入一個記錄，在undo log中就會有一個刪除記錄的操作，更新一個記錄，undo就做反向更新，同理刪除操作undo log就記錄一個插入操作。

插入1W條記錄後反向操作，可能會使得頁變得更大。

相關引數

Mysql程式碼  

1. innodb_undo_directory   用來設定rollback segment檔案所在的路徑  
2. innodb_undo_logs    用來設定rollback segment的個數，預設為128  
3. innodb_undo_tablespaces 用來設定構成rollback segment檔案的數量  

事務提交後並不會馬上刪除undo log，這是因為還有其他事務需要undo log來得到之前的版本，能否刪除undo log由purge執行緒判斷

為了保證事務併發操作時，在寫各自的undo log時不產生衝突，InnoDB採用回滾段的方式來維護undo log的併發寫入和持久化。回滾段實際上是一種 Undo 檔案組織方式，每個回滾段又有多個undo log slot。

相關推薦