MySQL InnoDB存储引擎
呵呵噠。。。
?
MySQL體系結構和存儲引擎
首先要搞懂的是什么是數據庫，什么是數據庫實例。
數據庫：物理操作系統文件或其他形式文件類型的集合。
實例：MySQL數據庫由后臺線程以及一個共享內存區組成，實例才是真正對數據庫進行操作的。
譬如：數據庫就像蓋樓所需的石頭、砂和水泥等原材料，而正在使用這些原材料蓋樓的施工隊則是實例，哈哈。
?
MySQL實例啟動的方法有很多種，啟動時讀取配置文件，如果配置文件有多個，而且配置項又有很多相同的，那么會以最后讀到的配置項為準。
?
數據庫實例是一層數據庫管理軟件，用戶不能直接地操縱數據庫，只能通過實例提供的接口來訪問數據庫。
圖1 MySQL體系結構
從圖1中可以發現，MySQL又一下幾部分組成：
- 連接池組件：Connectors
- 管理服務和工具組件：Management Service & Utilities
- SQL接口組件：SQL Interface
- 查詢分析器組件：Parser
- 優化器組件：Optimizer
- 緩沖組件：Caches & Buffers
- 插件式存儲引擎：Pluggable Storage Engines
- 物理文件：Files & Logs
MySQL的這個架構模式在很多數據庫中都有體現，你可以學一下MySQL這個架構，好歹也是架構啊！
MySQL數據庫的特色就是插件式的表存儲引擎。
MySQL插件式存儲引擎架構提供了一系列標準的管理和服務支持。
存儲引擎是底層物理結構的實現，每個存儲引擎開發者可以按照自己的意愿進行開發。
??? 注意：
??????? 存儲引擎是基于表的，而不是數據庫的！
?
存儲引擎的好處是：
- 每個存儲引擎都有各自的特點，可以根據具體的應用不同選擇/建立不同的存儲引擎表。
- 對于上層應用的開發來說，存儲引擎是透明的。
- MySQL數據庫的核心在于存儲引擎。
- MySQL官方手冊給出了編寫自定義存儲引擎的過程（可以去看下咯）。
?
常見的存儲引擎有（不能詳寫了，木有時間了）：
InnoDB、MyISAM、NDB、Memory、Archive、Federated、Maria；
其他的有：Merge、CSV、Sphinx、Infobright
至于存儲引擎之間的比較，讓他們見鬼去吧， 哦，我的上帝~
?
查看當前MySQL數據庫所支持的引擎：SHOW ENGINES\G;
MySQL自帶的示例數據庫和數據庫的文檔放在一起，下載地址：http://dev.mysql.com/doc/
?
連接MySQL
連接MySQL操作是一個連接進程和MySQL數據庫實例進行通信，本質上是進程通信（還好老子看了點，不然就懵逼了），常見的進程通信方式有：
管道、命名管道、命名名字、TCP/IP套接字、UNIX域套接字。
TCP/IP套接字：在任何平臺下都可以使用，也是使用最多的一種，通過TCP/IP連接MySQL實例時，MySQL會先檢查一張權限視圖，判斷請求客戶端IP是否允許連接到實例；
SELECT host, user, password FROM user;
命名管道和共享內存：
UNIX域套接字：在Linux和Unix下可以使用UNIX域套接字，這個并不是一個網絡協議，所以只能在客戶端和數據庫實例在同一臺機器的情況下使用。
制定套接字文件的路徑：—socket=/tmp/mysql.sock
SHOW VARIABLES LIKE 'socket';
?
好了，這章就看完了，遺留的就是對不同存儲引擎的介紹和比較咯。。。。。。
?
?
InnoDB存儲引擎
?
InnoDB是事物安全的MySQL存儲引擎，是OLTP應用中核心表的首選存儲引擎。
InnoDB是MySQL中第一個完整支持ACID事物的存儲引擎，其特點是：
行鎖設計
支持MVCC
支持外鍵
提供一致性非鎖定讀
有效利用CPU和內存
?
從MySQL5.1版本開始，允許存儲引擎以動態方式加載，這樣存儲引擎的更新可以不受MySQL數據庫版本的限制。
所以5.1中可以有靜態編譯的版本，也可以有動態加載的版本。
?
InnoDB體系架構
?
圖2 InnoDB存儲引擎體系架構
InnoDB存儲引擎有多個內存塊，可以認為這些內存塊組成了一個大的內存池，負責：
維護所有進程/線程需要訪問的多個內部數據結構
緩存磁盤上的數據
重做日志的緩沖（redo log）
?
后臺線程的主要作用是負責刷新內存池中的數據，保證緩沖池內的數據是最近的數據；同時將臟數據刷回磁盤；保證數據庫發生異常時InnoDB的恢復。
?
InnoDB是一個多線程模型，每個線程負責不同的任務。
1. Master Thread
2. IO Thread
3. Purge Thread
4. Page Cleaner Thread
?
內存
1. 緩沖池
2. LRU List、Free List和Flush List
3. 重做日志緩沖
4. 額外的內存池
?
CheckPoint技術
?
Master Thread工作方式
?
InnoDB的關鍵特性
插入緩沖（Insert Buffer）
兩次寫（Double Write）
自適應哈希索引（Adaptive Hash Index）
異步IO（Async IO）
刷新鄰接頁（Flush Neighbor Page）
?
啟動、關閉與恢復
?
小結：感覺這章的內容還是挺重要的，對于理解InnoDB引擎或者底層實現
?
文件
MySQL和InnoDB存儲引擎用到的文件有：
參數文件：
日志文件：
socket文件：
pid文件：
MySQL表結構文件：
存儲引擎文件：
?
?
?
表
?
InnoDB存儲引擎表的邏輯存儲和實現，重點分析表的物理存儲特征，即表中的數據是如何組織和存放的。
?
索引組織表
?
在InnoDB存儲引擎中，表都是根據主鍵順序存放的，這種存儲方式的表稱為索引組織表（index organized table）。
在InnoDB存儲引擎表中，每張表都有個主鍵（Primary Key），如果創建表時沒有顯式地定義主鍵，則InnoDB存儲引擎會按照如下方式選擇或者創建主鍵：
首先判斷表中是否有非空的唯一索引（Unique NOT NULL），如果有，則該列即為主鍵；
如果不符合上述條件，InnoDB存儲引擎將選擇建表時定義一個非空唯一索引主鍵。注意，主鍵的選擇是根據的是定義索引的順序，而不是建表時列的順序。
?
?
InnoDB邏輯存儲結構
?
在InnoDB中所有的數據都被邏輯地存放在一個空間中，稱之為表空間（tablespace）。表空間又由段（segment）、區（extent）、頁（page）組成。頁在一些文檔中也稱之為塊（block）。
?
圖 InnoDB邏輯存儲結構
表空間
?
?
段
?
區
?
頁
?
行
?
?
InnoDB行記錄格式
?
InnoDB存儲引擎和大多數的數據庫一樣，記錄是以行的形式存在的。即頁中保存著表中一行行的數據。
在InnoDB 1.0.x版之前，InnoDB引擎提供了Compact和Redundant兩種格式來存放行記錄數據，這也是目前用得最多的，Redundant是為了兼容之前的版本而保留的。
數據庫實例的作用之一就是讀取頁中存放的行記錄。如果用戶知道野種行記錄的組織規則，也可以自行編寫工具讀取記錄。
?
分表講了一下Compact行記錄格式和Redundant行記錄格式。
?
?
行溢出數據
?
?
Compressed和Dynamic行記錄格式
?
Char個行記錄格式
?
InnoDB數據頁結構
?
頁是InnoDB引擎管理數據庫的最小磁盤單位。頁類型為B-tree Node的頁存放的即是表中行的實際數據了。
?
?
Named File Formats機制
?
InnoDB存儲引擎通過Named File Formats解決不同版本下頁結構的兼容性問題。
?
?
約束
?
?
視圖
?
分區表：水平分區和垂直分區
?
?
索引與算法
索引太多，程序的性能受到影響；
索引太少，查詢的性能又會受到影響。So，必須找到一個平衡點。
?
?
對于數據的使用，從一開始就應該添加索引。
開發人員往往對于數據庫的使用停留在應用層面，比如編寫SQL語句、存儲過程之類的，甚至不知道索引的存在。
DBA往往不夠了解業務的數據流，而添加索引需要通過監控大量的SQL語句進而從中找到問題。這個步驟所需的時間肯定大于當初添加索引所需要的時間。索引也不是越多越好，索引越多導致磁盤占用很高。
?
這里對索引的內部機制了解，通過了解內部索引來了解哪里可以使用索引。
?
InnoDB存儲引擎索引的概述
?
InnoDB支持的索引類型有：B+樹索引、全文索引、哈希索引
?
InnoDB支持的哈希索引是自適應的，InnoDB存儲引擎會根據表的使用情況自動為表生成哈希索引，不能人為干預是否在一張表中生成哈希索引。
自適應哈希索引
?
?
圖 全文索引
?
?
?
B+樹索引是傳統意義上的索引， 也是目前關系型數據庫中使用最多和最有效的索引。B不是binary的意思，而是balance的意思，可有效減少磁盤IO。
注意：B+樹索引并不能夠找到一個給定鍵值的具體行。B+樹索引只能找到被查詢數據行所在的頁。然后通過將其讀入內存，再在內存中進行查找。
?
?
?
?
?
數據結構與算法
?
關于B+ tree的
二分查找法（binary search）：二分查找應用廣泛，思想易于理解，但是直到1962年才有了第一個完全正確的二分查找法。
?
二叉查找樹和平衡二叉樹
?
B+樹和二叉樹、平衡二叉樹一樣都是經典的數據結構。
B+樹由B樹和索引順序訪問方法（ISAM）演化而來，但是現實中已經沒有使用B樹的情況了。
B+樹的定義很復雜，總而言之：B+樹是為磁盤或其他直接存取輔助設備設計的一種平衡查找樹。
?
圖 高度為2的B+樹
?
B+樹的插入操作
B+樹的插入必須保證插入以后葉子節點中的記錄依然排序，同時要考慮到插入到B+樹中的三種情況，每個情況都有不同的插入算法。
圖 B+樹插入數據的三種不同情況
?
不管怎么插入數據，B+樹總是會保持平衡，但是為了平衡性，對新插入的鍵值可能需要做大量的拆分頁（split）操作。
因為B+樹結構主要用于磁盤，頁的拆分意味著磁盤操作，所以應當盡量減少頁的拆分操作。
所以B+樹提供了類似于平衡二叉樹的旋轉（Rotation）功能。
?
旋轉發生在Leaf Page已滿，但是左右兄弟節點沒有滿的情況下，B+樹不會急于做拆分操作，而是將記錄轉移到所在頁的兄弟節點上。
通常會先對左兄弟檢查來做旋轉操作。采用旋轉操作使得B+樹減少了一次頁的拆分操作。
?
B+樹的刪除操作
B+樹使用填充因子（fill factor）來控制樹的刪除變化，50%是填充因子的最小值。B+樹的刪除操作同樣必須保證刪除后葉子節點中的記錄依然排序，刪除也要考慮三種情況：
如果刪除之后，Fill Factor小于50%，那么需要做合并操作。
?
B+樹索引
?
B+樹索引的本質就是B+樹在數據庫中的實現。但是B+樹在數據庫中的特點是高扇出性，什么鬼？就是葉節點多。
因此數據庫中，B+樹的高度一般都是在2~4層，也就是說查找某一鍵值最多需要2到4次IO。2~4次IO意味著查詢時間只要0.02~0.04秒。
?
?
?
?
數據庫中的B+樹索引可以分為聚集索引（clustered index）和輔助索引（secondary index）。
?
聚集索引
?
圖 聚集索引
?
圖 聚集索引
?
?
圖 聚集索引和非聚集索引的區別
?
InnoDB存儲引擎表是索引組織表，即表中的數據按照主鍵順序存放。
而聚集索引（clustered index）就是按照每張表的主鍵構造一顆B+樹，同時葉子節點中存放的即為整張表的行記錄數據，也將聚集索引的葉子節點稱為數據頁。
聚集索引的這個特性決定了索引組織表中數據也是索引的一部分。同B+樹數據結構一樣，每個數據頁都通過一個雙向鏈表來進行鏈接。
?
由于實際的數據頁只能按照一顆B+樹進行排序，因此每張表只能擁有一個聚集索引。在多數情況下，查詢優化器傾向于采用聚集索引，
因為聚集索引能夠在B+樹索引的葉子節點上直接找到數據。
此外由于定義了數據的邏輯順序，聚集索引能夠特別快地訪問針對范圍值的查詢。查詢優化器能夠快速地發現某一段范圍的數據頁需要掃描。
?
圖 聚集索引中的數據查找
?
圖 非聚集索引中的數據查找
注意，聚集索引如果按照特定的順序存放物理數據，那么維護成本會很高。所以聚集索引的存儲并不是物理上連續的，而是邏輯上連續的。
其中有兩點：一時前面說到的頁通過雙向鏈表鏈接，頁按照主鍵的順序排序；
另一點是每個頁中的記錄也是通過雙向鏈表進行維護的，物理存儲上可以同樣不按照主鍵存儲。
?
?
聚集索引的另一個好處是，它對于主鍵的排序查找和范圍查找的速度非常快，葉子節點的數據就是用戶所要查找的數據。
?
雖然有通過order by進行排序，但是實際過程中并不會進行所謂的filesort，這是聚集索引的特點之一。
?
另一個是范圍查找，即如果要查找主鍵某一范圍內的數據，通過葉子節點的上層中間節點就可以得到頁的范圍，之后直接讀取數據頁即可。
?
輔助索引
?
輔助索引（secondary index），也成為非聚集索引，葉子節點并不包含記錄的全部數據。葉子節點除了包含鍵值以外，每個葉子節點中還會包含了一個書簽（bookmark）。
該書簽用來告訴InnoDB存儲引擎哪里可以找到與索引對應的行數據。
由于InnoDB存儲引擎是索引組織表，因此InnoDB存儲引擎的輔助索引的書簽就是相應行數據的聚集索引鍵。
?
輔助索引的存在并不影響數據在聚集索引中的組織，因此每張表上可以有多個輔助索引。當通過輔助索引來尋找數據時，InnoDB存儲引擎會遍歷輔助索引并通過葉級別的指針
獲得指向主鍵索引的主鍵，然后再通過主鍵索引來找到一個完整的行記錄。
?
注意：輔助索引并不需要讀取數據頁，輔助索引中并不存放數據，全都是索引
?
圖 非聚集索引
?
?
圖 非聚集索引
?
?
圖 聚集索引與非聚集索引
上面這張圖表現的還不錯哦。
?
稱為堆表的表類型是將行數據按照插入的順序存放，堆表的特性決定了堆表上的索引都是非聚集索引，主鍵與非主鍵的區別只是是否唯一且非空（NOT NULL）。
此時書簽是一個行標識（Row Identifier， RID），可以用如"文件號：頁號：槽號"的格式來定位實際的數據行。
?
某些情況下堆表的確要比索引組織表更快，但也要考慮到數據是否需要更新，并且更新是否影響到物理地址的變更。
同時也不能忽視排序和查找。
非聚集索引的離散讀，但是一般的數據庫都通過實現預讀（read ahead）技術來避免多次的離散讀操作。
因此建立索引組織表還是堆表取決于具體應用。
?
圖 預讀
?
B+樹索引的分裂
?
之前講到的B+樹的分裂是最為簡單的一種情況，在數據庫中的B+樹分裂則有所不同。
因為之前的B+樹分裂并沒有涉及到并發，這是最難的一部分。
圖 B+樹的分裂
圖 B+樹的分裂
?
B+樹的分裂也并不總是從中間開始，這樣會導致頁空間的浪費。
?
?
InnoDB存儲引擎的Page Header中有以下幾個部分用來保存插入的順序信息：
PAGE_LAST_INSERT
PAGE_DIRECTION
PAGE_N_DIRECTION
通過這些信息，InnoDB存儲引擎可以決定是向左還是向右分裂，同時決定將分裂點記為哪一個。
?
?
B+樹索引的管理
?
索引的創建和刪除可以通過兩種方法，一種是ALTER TABLE，另一種是CREATE/DROP INDEX。
?
用戶可以設置對整個列的數據進行索引，也可以只索引一個列的開頭部分。
?
SHOW INDEX可以查看表中的索引信息。
?
Fast Index Creation
?
對于索引添加或者刪除這類DDL操作，MySQL數據庫的操作過程為：
首先創建一張新的臨時表，表結構為通過命令ALTER TABLE新定義的結構
然后把原表中數據導入到臨時表中
接著刪除原表
最后把臨時表重命名為原來的表名。
?
?
如果對一張很大的表進行索引的添加和刪除操作，那么將耗費較長時間，更關鍵的是，若有大量事物需要訪問正在被修改的表，這意味著數據庫不可用。
?
InnoDB從 1.0.x開始支持一種稱為FIC（快速索引創建）的索引創建方式。
?
對于輔助索引的創建，InnoDB存儲引擎會對創建索引的表上加一個S鎖。在創建的過程中不需要重建表。
?
刪除輔助索引則更為簡單了，InnoDB存儲引擎只需要更新內部視圖，并將輔助索引的空間標記為可用，同時刪除MySQL數據庫內部視圖上對該表的索引定義即可。
?
?
?
Online Schema Change
?
The openarkkit toolkit oak-online-alter-table
?
Online DDL
?
?
Cardinality值
?
?
什么是Cardinality
并不是在所有的查詢條件中出現的列都需要添加索引。
一般的經驗是，在訪問表中很少一部分時使用B+樹索引才有意義。
對于性別字段、地區字段、類型字段，它們的取值的范圍很小，稱為低選擇性。
?
?
相反，如果某個字段的取值范圍很廣，幾乎沒有重復，即屬于高選擇性，則此時使用B+樹索引是非常合適的。
?
?
如果查看索引是否是高選擇性的呢？
?
可以通過SHOW INDEX結果列中的Cardinality來觀察。
Cardinality值非常關鍵，表示索引中不重復記錄數量的預估值。
同時需要注意的是Cardinality是一個預估值，而不是準確值。
在實際應用中，Cardinality/n_rows_in_table應盡可能接近1，如果非常小，那么用戶需要考慮是否還有必要建立這個索引。
?
?
B+樹索引的使用
?
不同應用中使用B+樹索引
聯合索引
覆蓋索引
?
優化器選擇不使用索引的情況
?
?
索引提示
?
?
Multi-Range Read優化
?
?
ICP優化
?
?
哈希算法
?
InnoDB存儲引擎中的哈希算法
?
自適應哈希算法
?
全文檢索
?
?
鎖
?
?
開發多用戶的系統時，最大的難點在于：一方面要最大程度利用數據庫的并發訪問，另外一方面還要確保每個用戶能以一致的方式讀取和修改數據。
為此就需要鎖機制。
鎖也是數據庫區別于文件系統的一個關鍵特性。
?
這部分學習的是InnoDB如何對表中的數據進行鎖定，以及以怎樣的粒度鎖定數據。
?
?
什么是鎖？
?
?
鎖機制用于管理共享資源的并發訪問。InnoDB存儲引擎會在行級別上對表數據上鎖。
?
除了對數據表進行上鎖之外，InnoDB也會在內部對其他的很多資源使用鎖，從而允許對多種不同資源提供并發訪問。
例如操作緩沖池中的LRU列表，刪除、添加、移動LRU列表中的元素，為了保證一致性，必須有鎖的介入，從而提供完整性和一致性。
?
對于MyISAM引擎，其鎖是表鎖設計，并發情況下的讀沒有問題，但是并發插入時的性能就要差一些。
?
?
lock與latch
?
在數據庫中lock和latch都可以被稱為鎖，但是兩者的含義截然不同。
?
latch一般稱為閂鎖，因其要求鎖定的時間必須非常短，若持續的時間長，則應用性能會很差。在InnoDB存儲引擎中，latch有可以分為mutex（互斥量）和rolock（讀寫鎖）。其目的使用來保證并發線程操作臨界資源的正確性，并且通常沒有檢測死鎖的機制。
?
lock的對象是事務，用來鎖定的是數據庫中的對象，如表、頁、行。并且一般lock的對象僅在事務commit或者rollback后進行釋放（不同事務隔離級別釋放的時間可能不同）。lock是有死鎖機制的。
?
?
?
?
SHOW ENGINE INNODB MUTEX可以查看InnoDB存儲引擎中的latch，輸出結果的解釋如下：
以上的信息都是比較底層的，一般僅供開發人員參考，但是用戶還是可以使用這些參數進行調優。
?
?
InnoDB存儲引擎中的鎖
?
鎖的類型
?
InnoDB存儲引擎實現了如下兩種標準的行級鎖：
共享鎖（S Lock），允許事務讀一行數據。
排他鎖（X Lock），允許事務刪除或更新一行數據。
?
?
如果一個事務T1已經獲取行r的共享鎖，那么另外的事務T2可以立即獲取行r的共享鎖，因為讀取并沒有改變行r的數據，這種情況稱為鎖兼容（Lock Compatible）。
但若有其他的事務T3想獲取行r的排他鎖，則其必須等待事務T1、T2釋放行r上的共享鎖——稱之為鎖不兼容。
?
X鎖與任何鎖都不兼容，而S鎖僅與S鎖兼容。需要注意的是X和S都是行鎖，兼容是指對同一記錄（row）鎖的兼容情況。
?
此外InnoDB存儲引擎支持多粒度（granular）鎖定，這種鎖定允許事務在行級別上的鎖和表級上的鎖同時存在。
?
為了支持不同粒度上的鎖，InnoDB存儲引擎有一個額外的鎖方式，稱之為意向鎖（Intention Lock）。意向鎖是將鎖定的對象分為多個層次，意向鎖意味著事務希望在更細粒度（fine granularity）上進行加鎖。
?
如果把上鎖的對象看做一顆樹，那么對最下層的對象上鎖，也就是對最細粒度的對象上鎖，那么首先需要對粗粒度的對象上鎖。
?
如需對頁上的記錄r進行上X鎖，那么分別需要對數據庫A、表、頁上意向鎖IX，最后對記錄r上X鎖。
其中任何一部分導致等待，那么該操作需要等待粗粒度鎖的完成。
?
舉例就是，對記錄r加X鎖之前，已經有事務對表1進行了S表鎖，那么表1上已經存在了S鎖，之后事務需要對記錄r在表上加IX，由于不兼容，所以對該事務需要等待表鎖操作的完成。
?
InnoDB存儲引擎支持的意向鎖設計比價簡單，其意向鎖為表級別的鎖。設計目的主要是為了在一個事務中揭示下一行將被請求的鎖類型。
1. 意向共享鎖（IS Lock），事務想要獲得一張表中某幾行的共享鎖
2. 意向排他鎖（IX Lock），事務想要獲得一張表中某幾行的排他鎖
?
由于InnoDB存儲引擎支持的是行級別的鎖，因此意向鎖其實不會阻塞除全表掃描以外的任何請求。
?
?
用戶可以通過命令SHOW ENGINE INNODB STATUS命令來查看當前鎖請求的信息。
?
可以看到SQL語句select * from? where a<4 lock in share mode在等待，
RECORD LOCKS space id 30 page no 3 n bits 72 index 'PRIMARY' of table 'test'.'t' trx id 48B89DB lock_mode X locks rec but not gap表示鎖住的資源。
locks rec but not gap代表鎖住的是一個索引，不是一個范圍。
?
在InnoDB 1.0版本之前，用戶只能通過命令SHOW FULL PROCESSLIST，SHOW ENGINE INNODB STATUS等來查看當前數據庫中的鎖請求，然后再判斷事務鎖的情況。
從InnoDB1.0開始，INFORMATION_SCHEMA架構下添加了表INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS。
通過這三張表，用戶可以更加單地監控當前事務并分析可能存在的問題。
?
?
?
?
一致性非鎖定讀（consistent nonlocking read）指的是InnoDB存儲引擎通過多行版本控制（multi versioning）的方式來讀取當前執行時間數據庫中行的數據。
?
如果讀取的行正在執行DELETE或者UPDATE操作，這時讀取操作不會因此去等待行上鎖的釋放，相反的，InnoDB存儲引擎會讀取行的一個快照數據。
?
?
?
之所以成為非鎖定讀，是因為不需要等待訪問的行上X鎖的釋放。
?
快照數據是指該行的之前版本的數據，該實現是通過undo段來完成。而undo用來在事務中回滾數據，因此快照數據本身是沒有額外的開銷。
此外快照數據的讀取是不需要上鎖的，因為沒有事務需要對歷史數據進行修改操作。
?
?
非鎖定讀機制極大提高了數據庫的并發性。
在InnoDB存儲引擎的默認設置下，這是默認的讀取方式，即讀取不會占用和等待表上的鎖。
?
但是在不同事務隔離級別下，讀取的方式不同，并不是在每個事務隔離級別下都是采用非鎖定的一致性讀。
此外即使使用非鎖定的一致性讀，但是對于快照數據的定義也各不相同。
?
快照數據就是當前行數據之前的歷史版本，每行記錄可能有多個版本。一行記錄可能有不止一個快照數據，一般稱這種技術為行多版本控制，由此帶來的并發控制，
稱為多版本并發控制（Multi Version Concurrency Control，MVCC）。
?
在事務隔離級別READ COMMITTED和REPEATABLE READ（InnoDB存儲引擎默認的隔離級別）下，InnoDB存儲引擎使用的是非鎖定的一致性讀。
然后對于快照數據的定義卻不一樣。
?
在READ COMMITTED事務隔離級別下，對于快照數據，非一致性讀總是讀取被鎖定行的最新一份快照數據（fresh snapshot）。
而在REPEATEABLE READ事務隔離級別下，對于快照數據，非一致性讀總是讀取事務開始時的行數據版本。
?
?
BEGIN;
COMMIT;
?
?
?
非一致性鎖定讀
?
在默認配置下，即事務隔離級別為REPEATABLE READ模式下，InnoDB存儲引擎的SELECT操作使用一致性非鎖定讀。
但是在某些情況下，用戶需要顯式地對數據庫操作進行加鎖以保證數據邏輯的一致性。
而這要求數據庫支持加鎖語句，即使對于SELECT的只讀操作。
InnoDB存儲引擎對于SELECT語句支持兩種一致性的鎖定讀（locking read）操作：
SELECT ..... FOR UPDATE
SELECT ..... LOCK IN SHARE MODE
?
SELECT ...... FOR UPDATE對讀取的行記錄加一個X鎖，其他事物不能對已鎖定的行加上任何鎖。
SELECT ...... LOCK IN SHARE MODE對讀取的行記錄加一個S鎖，其他事務可以向被鎖定的行加S鎖，但是如果加X鎖，則會被阻塞。
?
?
對于一致性非鎖定讀，即使讀取的行已被執行了SELECT ..... FOR UPDATE，也是可以進行讀取的。
此外，SELECT .... FOR UPDATE，SELECT ...... LOCK IN SHARE MODE必須在一個事務中，當事務提交了，鎖也就被釋放了。
?
因此在使用上面兩句SELECT的時候，務必加上begin，start transaction或者set autocommit=0。
?
?
自增長和鎖
?
外鍵和鎖
?
?
?
鎖的算法
?
行鎖的三種算法：
Record Lock：單行記錄的鎖
Gap Lock：間隙鎖，鎖定一個范圍，但不包含記錄本身
Next-key Lock：Gap Lock + Record Lock，鎖定一個范圍，并鎖定記錄本身
?
解決Phantom Problem
?
?
鎖問題
?
臟讀
?
臟讀就是指在不同的事務下，當前事務讀到了另外事務未提交的數據。
?
不可重復讀
?
丟失更新
?
?
阻塞
?
?
死鎖
?
死鎖的概念
?
?
死鎖概率
?
?
死鎖示例
?
鎖升級
?
事務
?
數據庫中事務的目的：事務會把數據庫從一種一致狀態轉為另一種一致狀態。
在數據庫提交工作時，要么確保所有修改都已經保存了，要么所有修改都不保存。
?
ACID
原子性（atomicity）
一致性（consistency）
隔離性（isolation）
持久性（durability）
?
認識事務
?
事務有著嚴格的定義，必須同時滿足四個特性，但是數據庫廠商出于各種目的，并沒有嚴格去滿足事務的ACID標準。
對于InnoDB存儲引擎而言，其默認的事務隔離級別READ REPEATABLE，完全遵循和滿足事務的ACID特性。
?
分別介紹事務的四個特性
?
事務的分類
?
扁平事務（Flat Transaction）
帶有保存點的扁平事務（Flat Transaction with Savepoints）
鏈事務（Chained Transactions）
嵌套事務（Nested Transactions）
分布式事務（Distributed Transactions）
?
?
?
事務的實現
?
?
事務控制語句
?
隱式提交的SQL語句
?
?
對事物操作的統計
?
每秒事務處理能力（Transaction Per Second）
?
事務的隔離級別
?
?
分布式事務
?
?
不好的事務習慣
?
?
長事務
?
?
備份與恢復
?
?
?
性能調優
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的MySQL InnoDB存储引擎的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Windows常用运行库下载 (Dire
- 下一篇： mysql中的boolean tinyi