MySQL學習總結 （InnoDB）

主要內容：

1. 存儲結構
2. 索引
3. 鎖
4. 事務

存儲結構

1. 表
   • 索引組織表：表是根據主鍵順序組織存放的。若是表中沒有非空唯一索引，引擎會自動建立一個6字節大小的指針。
   • 主鍵的索引是定義索引的順序，而不是建表時列的順序。
   • 表空間：邏輯結構的最高層，全部的數據都存放在表空間中。
   • 段：表空間由各個段組成，常見的段有數據段、索引段、回滾段等。
   • 數據即索引 ，索引即數據。
   • 區：區是由連續頁組成的空間，在任何狀況下每一個區的大小都爲1MB。
   • 引擎頁的大小爲16KB,即一個區中一共有64個連續的頁。
   • 頁（也叫塊）：是InnoDB磁盤管理的最小單位。默認每一個頁的大小爲16KB.新版本中能夠設置爲4，8，16k。
   • 行：數據是按行存儲。每一個頁最多容許存放7992行記錄。
2. 行記錄格式
   • Compact行記錄是在MySQL5.0中引入。一個頁中存放的數據越多，其性能就越高。
   • 變長字段的長度不能超過2字節，由於VARCHAR類型的最大長度爲65535。
   • 行溢出數據：通常認爲，BLOB、LOB這類的大對象列類型的存儲會把數據存放在數據頁面以外。
   • 經過實際測試發現能存放VARCHAR類型的最大長度爲65532.
   • MySQL官方手冊中定義的65535長度是指全部VARCHAR列的長度總和，若是列的長度總和超過這個長度，依然沒法建立
   • VARCHAR（N）,CHAR(N) N是指字符的長度，不是字節的長度。
3. 頁結構
   • B+樹索引自己並不能找到具體的一條記錄，能找到的只是該記錄所在的頁。
   • 約束和索引的區別：結束是一個邏輯的概念，用來保證數據的完整性，而索引是一個數據結構，既有邏輯上的概念，在數據庫中還表明着物流存儲的方式。

索引

1. B+樹中的B表明的是balance(平衡)，而不是binary(二叉)，由於B+樹是從最先的平衡二叉樹演化而來，可是B+樹不是一個二叉樹。
2. 對於某一條具體的記錄的查詢是經過對Page Directory進行二分查找獲得的。
3. 平衡二叉樹的定義以下：首先符合二叉樹查找 的定義，其次必須知足任何節點的兩個子樹的高度最大差爲1。
4. 彙集索引就是按照每張表的主鍵構造一棵B+樹，同時葉子節點中存入的即爲整張表的行記錄數據，也將彙集索引的葉子節點稱爲數據頁。
5. 索引組織表中的數據也是索引的一部分。每一個數據頁都經過一個雙向鏈表來進連接 。
6. 輔助索引：葉子節點並不包含行記錄的所有數據。葉子節點除了包含鍵值之外，每一個葉子節點中的索引 行中還包含了一個書籤，用來告訴InnoDB存儲引擎哪裏能夠找到與索引 相對應的行數據。
7. 當經過輔助索引來查找數據時，InnoDB會遍歷輔助索引並經過葉級別指針得到指向主鍵索引的主鍵，再經過主鍵索引 來找到一個完整的行記錄。
8. Microsoft SQL Server 有一種稱爲堆表的表類型，即行數據的存儲按照插入的順序存放。
9. Cardinality:表示索引 中唯一值（不重複記錄）的數目的估計值。這個值很是關鍵，優化器會根據這個值來判斷是否使用這個索引 。可是這個值不是實時更新的，即並不是每次索引的更新都會更新該值，緣由是代價過大，因此這個值是一個估計值。 也把這個值稱爲可選擇性。引擎一般經過採樣的方式來完成Cardinality的統計。

10. 覆蓋索引：即從輔助索引就能夠等到查詢的記錄，不須要查詢彙集索引中的記錄。

    一般查詢索引列或者count值會用覆蓋索引

11. 優化器不使用索引：在範圍查找或者JOIN連接操做時，有可能不使用索引 。
12. 強制使用索引 ：FORCE INDEX
13. 索引提示：USE INDEX
14. 若是肯定指定某個索引來完成查詢，那麼最可靠的是FORCE INDEX，而不是USE INDEX
15. Multi-Range Read(MRR):爲了減小磁盤的隨機訪問，而且將隨機訪問轉化爲較爲順序的數據訪問。具體作法：在查詢輔助索引時，首先根據等到的查詢結果，按照主鍵進行的順序，並按照主鍵排序的順序進行書籤查找 （explain 會有Using MRR）
16. Index Condition Pushdown(ICP)優化：優化以前-查詢索引，先根據索引來查找 記錄，而後再根據where條件來過濾記錄。 優化以後-在取出 索引的同時，判斷是否能夠進行where條件的過濾，即將where的部分過濾操做放在地了存儲引擎層。在一些查詢條件下，能夠大大減小上層SQL層對記錄的索取(fetch),從而提升數據庫性能。（explain 會有 Using index condition）
17. 哈希算法：採用鏈表的方式解決衝突，除法散列。

18. 自適應哈希索引：是數據庫自身建立並使用的，不能對其進行干預。

鎖

1. 鎖機制：是數據庫系統區別於文件系統的一個關鍵特性。提供數據的完整性與一致性。
2. InnoBD存儲引擎不須要鎖升級，由於一個鎖和多個鎖的開銷是相同的。
3. InnoDB實現了兩種鎖：共享鎖（S Lock）與排他鎖（X Lock）。
4. 共享鎖：容許事務讀一行數據。排他鎖：容許事務刪除或者更新一行數據。X與S都是行鎖
5. InnoDB存儲引擎支持意向鎖設計比較簡練，即意向鎖就是表級別的鎖。設計目的就是爲了在一個事務中提示下一行將被請求的鎖類型。分爲：意向共享鎖（IS Lock,事務想要 得到一張表中某幾行的共享鎖）,意向排他鎖（IX Lock事務想要 得到一張表中某幾行的排他鎖）
6. 由於InnoDB存儲引擎支持的是行級別的鎖，因此意向鎖不會阻塞除全表掃之外的任何請求。
7. 一致性非鎖定讀：經過多版本控制 的方式來讀取當前執行時間數據庫中行的數據。若是讀取的行正在執行DELETE或者UPDATE操做，這裏讀取操做不會所以等待行上的鎖釋放。引擎會讀取行的一個快照數據。
8. 一致性鎖定讀：SELECT ... FOR UPDATE （對讀取的行記錄加一個X鎖）或者 SELECT ... LOCK IN SHARE MODE（對讀取的行記錄加一個S鎖，其它事務能夠向被鎖的行加S鎖，若是加X鎖，則會被阻塞）
9. 行鎖3種算法：Record Lock-單個行記錄上鎖。Gap Lock-間隙鎖，鎖定一個範圍，但不包含記錄自己。Next-Key Lock:Gap+Record
10. Gap Lock:爲了阻止多個事務將記錄插入到同一範圍內，這個致使Phantom Problem（幻讀）產生。能夠經過：事務隔離級別設置爲RC關閉Gap Lock.
11. Phantom Problem：指在同一事務下，連續執行兩次一樣的SQL語句，可能致使不一樣的結果 ，第二次的SQL語句可能會返回以前不存在的行。
12. 髒頁：在緩衝池中已經被修改的頁，可是尚未提交刷新到磁盤中。日誌都已經寫入到重作日誌文件中。髒數據 ：指事務對緩衝池中的行記錄的修改，而且尚未被提交。
13. 不可重複讀：在一個事務內讀取一組數據，在這個事務尚未結束時，另外的事務對這組數據 進行了修改並提交了事務，此時，第一個事務再次讀取數據，可能和第一次讀取的數據 不一致。
14. 不可重複讀與髒讀的區別：髒讀是讀取未提交的數據 ，不可重複讀是讀取已經提交的數據。
15. InnoDB不會回滾超時引起的錯誤異常。可是發現死鎖後會回滾。

事務

1. ACID:原子性(automicity)、一致性(consistency)、隔離性(isolation)、持久性(durability)。
2. 原子性、一致性、持久性經過數據庫的redo log 和undo log來完成。redo log是重作日誌，保證事務的原子性和持久性。undo 保證事務的一致性。redo恢復提交事務修改的頁操做，undo回滾行記錄到某個待定版本。二者記錄的內容不一樣，redo經過是物理操做，記錄的是頁的物流修改操做。undo是邏輯日誌，根據系統自動記錄進行記錄。
3. binlog與redo log的不一樣：binlog是在MySQL數據庫的上層產生，不只針對InnoDB，任何存儲引擎對於數據的更改都會產生binlog. binlog是一種邏輯日誌，記錄的是對應的SQL語句。redo log是物理格式日誌，記錄的是對每一個頁的修改。
4. binlog只在事務提交時一次寫入，redo log是不停地寫入，與事務提交順序不一樣。
5. undo是邏輯日誌，只是將數據庫邏輯地恢復到原來的樣子。全部修改被取消了，可是數據結構和頁自己在回滾以後可能大不同了。除了回滾，undo的另一個做用是MVCC，undo log會伴隨着redo log產生，由於undo log須要持久化。
6. 四種隔離級別：READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ /SERIALIZABLE
7. MySQL老是自動提交的。