根據《MySQL技術內幕+InnoDB存儲引擎》一書的學習記錄

2018/12/22 號記錄

第一章：體系結構

1.1、關於數據庫與數據庫實例的理解，實例應該理解爲管理這些數據的運行程序。

1.2、mysql體系結構

最底層都是文件系統，上面是存儲引擎，主要學習的是 innodb 引擎，innodb引擎是基於表的，它的表的數據是存在 ibd 文件之中。innodb使用MVCC 來達到高併發，同時較爲突出的特性還有插入緩衝，兩次讀，自適應hai哈希索引，預讀等。

innodb 存儲採用聚簇的方式，表中存儲的數據都是按照主鍵的順序進行存儲的，如果在建立表的時候不存在顯示指定的主鍵，innodb 會爲每一個元組生成一個 6 字節的 ROWID 作爲主鍵。

mysql的進程通信，網絡的進程通信有兩種，socket 與 tcp/ip 連接，本地進程通信爲命名管道與共享內存。

第二章：innodb 存儲引擎

2.1、關於後臺線程

四種線程，master thread，IO thread， purge thread，page cleaner thread。

關於 IO thread：

purge thread：在事務被提交之後，需要回收 undo 日誌文件頁，通過這個線程完成。可是設置多個提高效率。

page cleaner thread ：髒頁刷新線程，減輕 master thread 的壓力。

2.2、關於內存

加入緩衝池機制，buffer pool。在緩衝池中的數據頁類型有：索引、數據、undo、插入緩衝、自適應哈希索引、鎖信息、數據字典信息。允許多個緩衝池實例，哈希平均分配。自行配置。

LRU：修改緩衝的頁，引入 checkpoint 機制，一定規律刷新到磁盤。通過指定的（非直接加到頭部的）LRU 算法維護主要的索引頁與數據頁。每個頁 16KB。之後引入了壓縮頁（略，暫時瞭解），Free LIst 空閒頁列表，Flush List 髒頁列表。

重做日誌緩衝：redo log buffer，重做日誌文件的緩衝。

額外的內存池：數據結構自身的存儲空間。

checkpoint：用於判斷何時刷新髒頁到磁盤的機制。關於數據有改變的過程：每次事務提交之前，先是對重做日誌進行修改，先修改的是重做日誌緩衝，之後的事務執行，修改其他的頁數據（都先是緩衝修改），當髒頁都被刷新到次磁盤中後，這部分的重做日誌纔會相當於失效，宕機後不會影響這部分的內容？？？但是後面也說，無論事務是否提交重做日誌都會每秒刷新到磁盤，所以 checkpoint也需要在這裏強制產生？？？

關於checkpoint 具體發生時間：？？？？？？？？？

2.3、Master Thread 工作方式（？沒懂）

2.4、innodb 關鍵特性

2.4.1 insert buffer：

insert buffer 是物理頁，不是在緩衝池中。

關於插入與更新操作，在緩衝池之下的層次，主要是更新索引頁，插入或者更新節點。

插入緩衝的作用是針對非聚集的輔助索引。在進行插入操作的是，同時需要更新“所有”的索引頁，即聚集索引的節點需要添加，非聚集的輔助索引（需要該索引來查詢的）索引節點也需要插入（B+樹）。數據頁的存放還是按照主鍵順序。針對聚集索引（主鍵）的是順序的訪問，但是針對輔助索引的節點插入時隨機的，需要離散的訪問非聚集索引頁，導致性能下降。

緩衝池中有很多的非聚集索引頁，如果需要添加的輔助索引對應的索引頁在緩衝池，直接添加。不在則添加到insert buffer中，之後inser buffer 物理頁與對應的非聚集索引頁進行子節點的合併操作（相當於另外一個索引的緩衝池，多個一次性刷新）。這樣就會降低離散訪問（根據輔助索引查詢索引的時候需要遍歷）的次數，問題：每張表都會有一個索引頁？？？。並且插入的索引會相對順序。

佔用的是緩衝池的內存，但時實際是物理頁。不是緩衝池的組成部分？？？？

insert buffer 的升級版本是 change buffer:

insert buffer 的實現：

insert buffer 是使用 B+ 樹的結構，現在的版本全局只有一個 insert buffer，放在共享表空間中，即 ibdata1。一個B+數即一部分的數據內存塊，通過地址的不同尋址方式（每個內存空間都有對應的地址）形成的。

之後的具體插入細節看不懂？？？？

合併索引頁：

2018/12/23記錄

2.4.2 double write：

數據損壞問題：部分寫失效問題，因爲不同級別的IO單位不同，磁盤一個扇區大小 512 bytes，一個簇由很多的扇區組成，

對於文件系統的 IO 來說，一個文件需要佔用多個簇，且一個簇（8個扇區）只能有一個文件佔用。所以針對一個文件系統 IO 的最小單位一般是 4 KB。

針對數據庫來說，每個頁的大小是 16 KB。

所以一個髒頁刷線到磁盤的時候，16 K 的頁需要 32 個扇區，所以在這個過程中發生了宕機，後果即是頁的損壞。

insert buffer保證高效，double write 保證了數據的高可靠性。在寫操作失效的時候，一般是通過 redo 日誌進行重做，即從緩衝池刷新髒頁到磁盤的時候，發生了宕機，通過 redo 日誌重做存在一個問題，即該磁盤的物理頁損壞了，所以重做是沒有用的，所以在刷新到髒頁的時候，需要一個副本的存在。所以引入了 double write ，即刷新髒頁的時候，首先copy到的double write buffer（內存實例中，不在緩衝池中）中，先刷新到（物理磁盤上）共享表空間的 double write的2MB上，之後再同步到磁盤，如果同步到磁盤的操作出錯，那麼通過共享表空間連續的 128 個頁（128x16=2MB = 1 MB + 1 MB）內存，先恢復到之前的狀態再進行重做。

問題：既然 double write的內存中已經有了最新的，爲什麼直接使用 redo 恢復到最新的情況？還是說需要體現 redo的作用？

https://www.cnblogs.com/geaozhang/p/7241744.html 網上沒有說清楚。

2.4.3 adaptive hash index: 自適應哈希索引

自適應的哈希索引，針對等值查找的操作，如果某些查找模式如 where a = 'xxx' 或者 where a='xxx' and b= 'xxx’ 的出現頻率較高，那麼存儲引擎會針對這種模式，在B+樹以外針對某些熱點也建立哈希索引。比如一次查找先是根據B+樹的索引查到對應索引的對應頁，再去遍歷對應的頁。但是在B+樹的查找上面花的時間可以通過哈希索引提高效率。