MySQL架構體系

MySQL基本架構(一條SQL語句的執行過程)

MySQL主要能夠分爲Server層和存儲引擎層。
Server層包括鏈接器、查詢緩存、分析器、優化器、執行器等，全部跨存儲引擎的功能都在這一層實現。
存儲引擎層負責數據的存儲和提取。其架構模式是插件式的，支持InnoDB(5.5後成爲默認存儲引擎)、MyISAM、Memory等多個存儲引擎。

鏈接器:負責用戶登陸數據庫，進行用戶的身份認證，包括校驗帳戶密碼，權限等操做。

查詢緩存:客戶端與服務端創建鏈接後，MySQL在執行查詢語句時會先查詢緩存，校驗這條SQL是否是在以前執行過。以前執行過的語句及其結果會以key-value對的形式被直接緩存在內存中。(不建議使用查詢緩存，查詢緩存的失效很是頻繁，只要有對一個表的更新，這個表上全部的查詢緩存都會被清空。在MySQL8.0中已刪除該功能)

分析器:分析SQL語句的做用,主要分爲如下兩步
1.詞法分析，提取關鍵字
2.語法分析，判斷SQL語句是否正確

優化器:對SQL語句進行自動優化，對語法分析樹的形態進行修改，把語法分析樹變爲查詢樹，肯定執行方案。

執行器:執行語句。首先校驗用戶是否有執行查詢的權限，若是有權限，就會去調用引擎的接口，返回接口執行的結果。

存儲引擎InnoDB、MyISAM

經常使用的存儲引擎有如下幾種:
InnoDB引擎:Innodb引擎提供了對數據庫ACID事務的支持。而且還提供了行級鎖和外鍵的約束。它的設計的目標就是處理大數據容量的數據庫系統。
MyIASM引擎:不提供事務的支持，也不支持行級鎖和外鍵。
MEMORY引擎:全部的數據都在內存中，數據的處理速度快，可是安全性不高。

MyISAM與InnoDB的區別

關於全文索引:MySQL全文索引在5.7以前只支持英文，5.7以後內置了ngram全文檢索插件，用來支持中文分詞，對MyISAM和InnoDB引擎都有效。
該處具體到底如何筆者也仍然存在疑問，難以給出準確回答，可是在更多狀況下，全文索引咱們更傾向於使用elasticSearch等工具實現全文檢索。

InnoDB、MyISAM下索引實現的差別

MyISAM索引實現
MyISAM引擎使用B+Tree做爲索引結構，葉節點的data域存放的是數據記錄的地址。
MyISAM會按照數據插入的順序分配行號，從0開始，而後按照數據插入的順序存儲在磁盤上。由於行是定長的，因此能夠從表的開頭跳過相應的字節找到須要的行。
MyISAM的索引文件僅僅保存數據記錄的行號，而後經過此行號回表查詢須要的數據

在MyISAM中，主索引和輔助索引在結構上沒有任何區別，只是主索引要求Key是惟一的，而輔助索引的key能夠重複。

所以，MyISAM中索引檢索的算法爲首先按照B+Tree搜索算法搜索索引，若是指定的key存在，則取出其data域的值，而後以data域的值爲地址，讀取相應數據記錄。MyISAM的索引方式索引和數據存放是分開的，非彙集的。

InnoDB索引實現
雖然InnoDB也使用B+Tree做爲索引結構，但具體實現方式卻與MyISAM大相徑庭。在InnoDB中，表數據文件自己就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，所以InnoDB表數據文件自己就是主索引。
聚簇索引的每個葉子節點都包含了主鍵值、事務ID、用於事務和MVCC的回滾指針以及全部的剩餘列。
InnoDB的二級索引的葉子節點存儲的不是行號（行指針），而是主鍵列。這種策略的缺點是二級索引須要兩次索引查找，第一次在二級索引中查找主鍵，第二次在聚簇索引中經過主鍵查找須要的數據行。

綜上，二者都包含非聚簇索引的實現，可是InnoDB引擎支持了聚簇索引。

爲何InnoDB及MyISAM引擎都使用了B+Tree做爲索引

B樹與B+樹的比較:

1. B樹只適合隨機檢索，而B+樹同時支持隨機檢索和順序檢索
2. B+樹空間利用率更高，可減小I/O次數，磁盤讀寫代價更低。
   通常來講，索引自己也很大，不可能所有存儲在內存中，所以索引每每以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程當中就要產生磁盤I/O消耗。
   B+樹的內部結點並無指向關鍵字具體信息的指針，只是做爲索引使用，其內部結點比B樹小，盤塊能容納的結點中關鍵字數量更多，一次性讀入內存中能夠查找的關鍵字也就越多，相對的，IO讀寫次數也就下降了。而IO讀寫次數是影響索引檢索效率的最大因素。
3. B+樹的查詢效率更加穩定
   B樹搜索有可能會在非葉子結點結束，越靠近根節點的記錄查找時間越短，只要找到關鍵字便可肯定記錄的存在，其性能等價於在關鍵字全集內作一次二分查找。
   而在B+樹中，順序檢索比較明顯，隨機檢索時，任何關鍵字的查找都必須走一條從根節點到葉節點的路，全部關鍵字的查找路徑長度相同，致使每個關鍵字的查詢效率至關。
4. B樹在提升了磁盤IO性能的同時並無解決元素遍歷的效率低下的問題。
   B+樹的葉子節點使用指針順序鏈接在一塊兒，只要遍歷葉子節點就能夠實現整棵樹的遍歷，而B樹不支持這樣的操做。
5. 增刪文件（節點）時，B+樹效率更高。
   由於B+樹的葉子節點包含全部關鍵字，並以有序的鏈表結構存儲，這樣可很好提升增刪效率。

B+樹與hash索引的比較:
B+樹底層實現是多路平衡查找樹，hash索引底層是hash表。

1. hash索引進行等值查詢更快，可是卻沒法進行範圍查詢，且等值查詢不穩定，性能不可預測
   當某個鍵值存在且大量重複的時候，發生hash碰撞，這次hash索引效率可能極差
   b+樹的查詢效率比較穩定，對於全部的查詢都是從根節點到葉子節點，且樹的高度較低
2. hash索引不支持使用索引進行排序
3. hash索引不支持模糊查詢以及多列索引的最左前綴匹配
4. hash索引任什麼時候候都避免不了回表查詢，而B+樹在符合某些條件的時候能夠只經過索引完成查詢

B+樹對比二叉樹:
二叉樹當數據庫的數據量特別大時，其層數也特別大。磁盤IO的次數會由樹的高度決定，不使用二叉樹是爲了壓縮樹的高度，減小磁盤IO的次數。

索引的基本原理

索引的原理很簡單，就是把無序的數據變成有序的查詢
把建立了索引的列的內容進行排序
對排序結果生成倒排表
在倒排表內容上拼上數據地址鏈
在查詢的時候，先拿到倒排表內容，再取出數據地址鏈，從而拿到具體數據

InnoDB邏輯存儲結構

從InnoDB的邏輯存儲結構看，全部數據都被邏輯地存放在一個空間中，稱之爲表空間（tablespace）

表空間又由段（segment）、區（extent）、頁（page）組成
頁在一些文檔中有時也稱爲塊（block）
段、區均爲邏輯概念，而且段管理由innodb存儲引擎內部完成。

表空間:表空間能夠看作是InnoDB存儲引擎邏輯結構的最高層，全部的數據都存放在表空間中
默認狀況下InnoDB有一個共享表空間ibdata1，即全部數據都存放在這個表空間內

段:表空間是由多個段組成的，常見的段有數據段、索引段、回滾段等
InnoDB是索引組織的，所以數據即索引，索引即數據
數據段就是B+樹的葉子節點
索引段即爲B+樹的非葉子節點

區:區是由連續頁組成的空間，在任何狀況下每一個區的大小都爲1MB。爲了保證區中頁的連續性，InnoDB存儲引擎一次從磁盤申請4~5個區，即一個區中有64個連續的頁，

行(頁):InnoDB存儲磁盤管理的最小單位，頁的大小默認是16KB，每一個頁存放的記錄也是硬性定義的，最多容許存放16KB/2-200行記錄，即7992行記錄

InnoDB崩潰恢復原理

參考資料: https://www.cnblogs.com/coderyuhui/p/7191413.html 下文只作筆者我的的一些總結，具體的實現原理參考原文。

基礎知識

lsn：從數據庫建立以來產生的redo日誌量，這個值越大，說明數據庫的更新越多，也能夠理解爲更新的時刻。此外，每一個數據頁上也有一個lsn，表示最後被修改時的lsn，值越大表示越晚被修改。
好比，數據頁A的lsn爲100，數據頁B的lsn爲200，checkpoint lsn爲150，系統lsn爲300，表示當前系統已經更新到300，小於150的數據頁已經被刷到磁盤上，所以數據頁A的最新數據必定在磁盤上，而數據頁B則不必定，有可能還在內存中。

redo日誌：現代數據庫都須要寫redo日誌，例如修改一條數據，首先寫redo日誌，而後再寫數據。在寫完redo日誌後 ，就直接給客戶端返回成功。
這樣雖然看過去多寫一次盤，可是因爲把對磁盤的隨機寫入（寫數據）轉換成了順序的寫入（寫redo日誌），性能有很大幅度的提升。
當數據庫掛了以後，經過掃描redo日誌，就能找出那些沒有刷盤的數據頁（在崩潰以前可能數據頁僅僅在內存中修改了，可是還沒來得及寫盤），保證數據不丟。

undo日誌：數據庫還提供相似撤銷的功能，當你發現修改錯一些數據時，可使用rollback指令回滾以前的操做。這個功能須要undo日誌來支持。
此外，現代的關係型數據庫爲了提升併發（同一條記錄，不一樣線程的讀取不衝突，讀寫和寫讀不衝突，只有同時寫才衝突），都實現了相似MVCC的機制，在InnoDB中，這個也依賴undo日誌。
爲了實現統一的管理，與redo日誌不一樣，undo日誌在BufferPool中有對應的數據頁，與普通的數據頁一塊兒管理，依據LRU規則也會被淘汰出內存，後續再從磁盤讀取。與普通的數據頁同樣，對undo頁的修改，也須要先寫redo日誌。

檢查點checkPoint：數據庫爲了提升性能，數據頁在內存修改後並非每次都會刷到磁盤上。
checkpoint以前的數據頁保證必定落盤了，這樣以前的日誌就沒有用了(因爲InnoDB redolog日誌循環使用，這時這部分日誌就能夠被覆蓋)，checkpoint以後的數據頁有可能落盤，也有可能沒有落盤，
因此checkpoint以後的日誌在崩潰恢復的時候仍是須要被使用的。InnoDB會依據髒頁的刷新狀況，按期推動checkpoint，從而減小數據庫崩潰恢復的時間。檢查點的信息在第一個日誌文件的頭部。

崩潰恢復：用戶修改了數據，而且收到了成功的消息，然而對數據庫來講，可能這個時候修改後的數據尚未落盤，若是這時候數據庫掛了，重啓後，數據庫須要從日誌中把這些修改後的數據給撈出來，從新寫入磁盤，保證用戶的數據不丟。
這個從日誌中撈數據的過程就是崩潰恢復的主要任務，也能夠稱爲爲數據庫前滾。
固然，在崩潰恢復中還須要回滾沒有提交的事務，提交沒有提交成功的事務。因爲回滾操做須要undo日誌的支持，undo日誌的完整性和可靠性須要redo日誌來保證，因此崩潰恢復先作redo前滾，而後作undo回滾。

InnoDB崩潰恢復過程

1. redo日誌前滾數據庫
   前滾數據庫，主要分爲兩階段，首先是日誌掃描階段，掃描階段按照數據頁的space_id和page_no分發redo日誌到hash_table中，保證同一個數據頁的日誌被分發到同一個哈希桶中，且按照lsn大小從小到大排序。
   掃描完後，再遍歷整個哈希表，依次應用每一個數據頁的日誌，應用完後，在數據頁的狀態上至少恢復到了崩潰以前的狀態。

2. redo日誌解析

• 首先經過block_no和lsn之間的關係以及日誌checksum判斷是否讀到了日誌最後，若是讀到最後則返回。(以前說了，即便數據庫是正常關閉的，也要走崩潰恢復邏輯，那麼在這裏就返回了，由於正常關閉的checkpoint值必定是指向日誌最後)
  不然則把日誌去頭掐尾放到一個recv_sys->buf中，日誌頭裏面存了一些控制信息和checksum值，只是用來校驗和定位，在真正的應用中沒有用。
• 從recv_sys->buf中解析日誌。日誌分兩種：single_rec和multi_rec，前者表示只對一個數據頁進行一種操做，後者表示對一個或者多個數據頁進行多種操做。
• 解析出相應的日誌後，按照space_id和page_no進行哈希(若是對應的表空間在內存中不存在，則表示表已經被刪除了)，放到hash_table裏面(日誌真正存放的位置依然在buffer pool)便可，等待後續應用。

1. redo日誌應用
   主要做用就是遍歷hash_table，從磁盤讀取對每一個數據頁，依次應用哈希桶中的日誌。
   執行完了redo前滾數據庫，數據庫的全部數據頁已經處於一致的狀態，undo回滾數據庫就能夠安全的執行了。
   因爲數據庫崩潰的時候可能有一些沒有提交的事務或者已經提交的事務，故在這個時候須要決定是否提交。
   主要分爲三步，首先是掃描undo日誌，從新創建起undo日誌鏈表，接着是，依據上一步創建起的鏈表，重建崩潰前的事務，即恢復當時事務的狀態。最後，就是依據事務的不一樣狀態，進行回滾或者提交。

2. undo日誌回滾數據庫
   第一步: 遍歷整個undo日誌空間，若是發現某個undo segment非空，就進行segment初始化,若是發現某個undo slot非空，就進行slot 初始化。以後把不一樣類型的undo日誌放到不一樣鏈表中。
   undo日誌主要分爲兩種：TRX_UNDO_INSERT和TRX_UNDO_UPDATE。前者主要是提供給insert操做用的，後者是給update和delete操做使用。
   undo日誌有兩種做用，事務回滾時候用和MVCC快照讀取時候用。
   因爲TRX_UNDO_INSERT的數據不須要提供給其餘線程用，因此只要事務提交，就能夠刪除TRX_UNDO_INSERT類型的undo日誌。
   TRX_UNDO_UPDATE在事務提交後還不能刪除，須要保證沒有快照使用它的時候，才能經過後臺的purge線程清理。
   第二步：第一步中，已經在內存中創建起了undo_insert_list和undo_update_list(鏈表每一個undo segment獨立)，因此這一步只須要遍歷全部鏈表，重建起事務的狀態。
   若是undo日誌的狀態是TRX_UNDO_ACTIVE，則事務的狀態爲TRX_ACTIVE，若是undo日誌的狀態是TRX_UNDO_PREPARED，則事務的狀態爲TRX_PREPARED。
   重建起事務後，按照事務id加入到trx_sys->trx_list鏈表中。
   第三步:統計全部須要回滾的事務(事務狀態爲TRX_ACTIVE)一共須要回滾多少行數據，輸出到錯誤日誌中。
   第三步的操做在兩個地方被調用。一個是在recv_recovery_from_checkpoint_finish,另一個是在recv_recovery_rollback_active中。
   前者主要是回滾對數據字典的操做，也就是回滾DDL語句的操做，後者是回滾DML語句。前者是在數據庫可提供服務以前必須完成，後者則能夠在數據庫提供服務(也便是崩潰恢復結束)以後繼續進行(經過新開一個後臺線程trx_rollback_or_clean_all_recovered來處理)。
   由於InnoDB認爲數據字典是最重要的，必需要回滾到一致的狀態才行，而用戶表的數據能夠稍微慢一點，對外提供服務後，慢慢恢復便可。所以咱們經常在會發現數據庫已經啓動起來了，而後錯誤日誌中還在不斷的打印回滾事務的信息。

MySQL的鎖機制

MySQL鎖按照鎖的粒度劃分可分爲:行鎖、表鎖、頁鎖
行鎖:
行級鎖是MySQL中鎖定粒度最細的一種鎖，表示只針對當前操做的行進行加鎖。
行級鎖能大大減小數據庫操做的衝突。其加鎖粒度最小，但加鎖的開銷也最大。有可能會出現死鎖的狀況。
行級鎖按照使用方式分爲共享鎖和排他鎖。

共享鎖容許一個事務讀數據，不容許修改數據，若是其餘事務要對該行加鎖，只能加共享鎖。即共享鎖容許多個線程同時獲取一個鎖，一個鎖能夠同時被多個線程擁有。
排他鎖是修改數據時加的鎖，能夠讀取和修改數據，一旦一個事務對該行數據加鎖，其餘事務將不能再對該數據加任務鎖。即一個鎖在某一時刻只能被一個線程佔有，其餘線程必須等待鎖被釋放以後纔可能獲取到鎖。

表鎖:
表級鎖是MySQL鎖中粒度最大的一種鎖，表示當前的操做對整張表加鎖，資源開銷比行鎖少，不會出現死鎖的狀況，可是發生鎖衝突的機率很大。
被大部分MySQL引擎支持，MyISAM和InnoDB都支持表級鎖，可是InnoDB默認是行級鎖。

頁鎖:
頁級鎖是MySQL中鎖定粒度介於行級鎖和表級鎖中間的一種鎖。表級鎖速度快，但衝突多，行級鎖衝突少，但速度慢。
因此取了折中的頁級，一次鎖定相鄰的一組記錄。BDB支持頁級鎖。

樂觀鎖&悲觀鎖
數據庫管理系統(DBMS)中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。
樂觀併發控制(樂觀鎖)和悲觀併發控制(悲觀鎖)是併發控制主要採用的技術手段
要把樂觀併發控制和悲觀併發控制狹義的理解爲DBMS中的概念，更不要把他們和數據中提供的鎖機制（行鎖、表鎖、排他鎖、共享鎖）混爲一談。其實，在DBMS中，悲觀鎖正是利用數據庫自己提供的鎖機制來實現的。

悲觀鎖
悲觀併發控制(悲觀鎖)是一種併發控制的方法。它能夠阻止一個事務以影響其餘用戶的方式來修改數據。
若是一個事務執行的操做對其行數據應用了鎖，那只有當這個事務把鎖釋放，其餘事務纔可以執行與該鎖衝突的操做。
悲觀併發控制主要用於數據爭用激烈的環境，以及發生併發衝突時使用鎖保護數據的成本要地獄回滾事務的成本的環境中。

悲觀鎖的具體流程:
在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖。
若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。具體響應方式由開發者根據實際須要決定。
若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會解鎖了。
期間若是有其餘對該記錄作修改或加排他鎖的操做，都會等待咱們解鎖或者直接拋出異常。

悲觀鎖的優勢和不足：
悲觀鎖其實是採起了「先取鎖在訪問」的策略，爲數據的處理安全提供了保證。
可是在效率方面，因爲額外的加鎖機制產生了額外的開銷，而且增長了死鎖的機會。
而且下降了併發性；當一個事物因此一行數據的時候，其餘事物必須等待該事務提交以後，才能操做這行數據。

樂觀鎖
樂觀併發控制(樂觀鎖)是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務可以在不產生鎖的狀況下處理各自影響的那部分數據。
在提交數據更新以前，每一個事務會先檢查在該事務讀取數據後，有沒有其餘事務又修改了該數據。若是其餘事務有更新的話，正在提交的事務會進行回滾。

樂觀鎖相對悲觀鎖而言，樂觀鎖假設認爲數據通常狀況下不會形成衝突，因此在數據進行提交更新的時候，纔會正式對數據的衝突與否進行檢測，若是發現衝突了，則讓返回用戶錯誤的信息，讓用戶決定如何去作。
在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。通常的實現樂觀鎖的方式就是記錄數據版本。

數據版本，爲數據增長的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次同時對版本標識進行更新。
當咱們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，若是數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，不然認爲是過時數據。

樂觀鎖的優勢和不足：
樂觀併發控制相信事務之間的數據競爭(data race)的機率是比較小的，所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。
但若是直接簡單這麼作，仍是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，通過修改之後寫回數據庫，這時就遇到了問題。

InnoDB鎖的特性

1. 在不經過索引條件查詢的時候，InnoDB使用的確實是表鎖。
2. 因爲MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，因此雖然是訪問不一樣行的記錄，可是若是是使用相同的索引鍵，是會出現鎖衝突的。
3. 當表有多個索引的時候，不一樣的事務可使用不一樣的索引鎖定不一樣的行，另外，不管是使用主鍵索引、惟一索引或普通索引,InnoDB都會使用行鎖來對數據加鎖
4. 即使在條件中使用了索引字段，可是否使用索引來檢索數據是由MySQL經過判斷不一樣執行計劃的代價來決定的，若是MySQL認爲全表掃描效率更高，好比對一些很小的表，它就不會使用索引
   這種狀況下InnoDB將使用表鎖而不是行鎖。

MVCC

MVCC全稱是： Multiversion concurrency control，多版本併發控制，提供併發訪問數據庫時，對事務內讀取的到的內存作處理，用來避免寫操做堵塞讀操做的併發問題。
一個支持MVCC的數據庫，在更新某些數據時，並不是使用新數據覆蓋舊數據，而是標記舊數據是過期的，同時在其餘地方新增一個數據版本。所以，同一份數據有多個版本存儲，但只有一個是最新的。
MVCC提供了 時間一致性的 處理思路，在MVCC下讀事務時，一般使用一個時間戳或者事務ID來肯定訪問哪一個狀態的數據庫及哪些版本的數據。讀事務跟寫事務彼此是隔離開來的，彼此之間不會影響。假設同一份數據，既有讀事務訪問，又有寫事務操做，實際上，寫事務會新建一個新的數據版本，而讀事務訪問的是舊的數據版本，直到寫事務提交，讀事務纔會訪問到這個新的數據版本。
MVCC有兩種實現方式，第一種實現方式是將數據記錄的多個版本保存在數據庫中，當這些不一樣版本數據再也不須要時，垃圾收集器回收這些記錄。這個方式被PostgreSQL和Firebird/Interbase採用，SQL Server使用的相似機制，所不一樣的是舊版本數據不是保存在數據庫中，而保存在不一樣於主數據庫的另一個數據庫tempdb中。第二種實現方式只在數據庫保存最新版本的數據，可是會在使用undo時動態重構舊版本數據，這種方式被Oracle和MySQL/InnoDB使用。

InnoDB的MVCC實現機制

MVCC能夠認爲是行級鎖的一個變種，它能夠在不少狀況下避免加鎖操做，所以開銷更低。MVCC的實現大都實現了非阻塞的讀操做，寫操做也只鎖定必要的行。InnoDB的MVCC實現，是經過保存數據在某個時間點的快照來實現的。一個事務，無論其執行多長時間，其內部看到的數據是一致的。也就是事務在執行的過程當中不會相互影響。下面咱們簡述一下MVCC在InnoDB中的實現。

InnoDB的MVCC，經過在每行記錄後面保存兩個隱藏的列來實現：一個保存了行的建立時間，一個保存行的過時時間（刪除時間），固然，這裏的時間並非時間戳，而是系統版本號，每開始一個新的事務，系統版本號就會遞增。在RR隔離級別下，MVCC的操做以下：

select操做。InnoDB只查找版本早於（包含等於）當前事務版本的數據行。能夠確保事務讀取的行，要麼是事務開始前就已存在，或者事務自身插入或修改的記錄。行的刪除版本要麼未定義，要麼大於當前事務版本號。能夠確保事務讀取的行，在事務開始以前未刪除。insert操做。將新插入的行保存當前版本號爲行版本號。delete操做。將刪除的行保存當前版本號爲刪除標識。update操做。變爲insert和delete操做的組合，insert的行保存當前版本號爲行版本號，delete則保存當前版本號到原來的行做爲刪除標識。因爲舊數據並不真正的刪除，因此必須對這些數據進行清理，innodb會開啓一個後臺線程執行清理工做，具體的規則是將刪除版本號小於當前系統版本的行刪除，這個過程叫作purge。