page（邏輯）

• page應(yīng)用于InnoDBb表空間包括：系統(tǒng)表空間、單表文件表空間、常規(guī)表空間；
• page_size默認(rèn)16KB；足夠大以容納大多數(shù)行的數(shù)據(jù)，但足夠小以最小化將不需要的數(shù)據(jù)傳輸?shù)絻?nèi)存的性能開銷;

表

表的物理結(jié)構(gòu)

• .frm文件即包含MySQL表的元數(shù)據(jù)（例如表定義）的文件；
• 盡管每個(gè)InnoDB表都有一個(gè) .frm文件，但是InnoDB 在系統(tǒng)表空間中維護(hù)其自己的表元數(shù)據(jù)；

表移動(dòng)

• 可移動(dòng)表空間
  • 一個(gè)服務(wù)器實(shí)例復(fù)制到另一個(gè)服務(wù)器實(shí)例
  • FLUSH TABLES ... FOR EXPORT
  • innodb_file_per_table須設(shè)置為ON
• 復(fù)制數(shù)據(jù)文件（冷備份方法）
• 導(dǎo)出和導(dǎo)入（mysqldump）

索引

索引的物理結(jié)構(gòu)

• InnoDB 中除空間GIS索引（是R樹數(shù)據(jù)結(jié)構(gòu)）外，其他索引均為B樹結(jié)構(gòu)；

聚簇索引和二級(jí)索引（輔助索引）

• 每個(gè)InnoDB 表都有一個(gè)特殊的索引，稱為聚簇索引 ，通常稱之為主鍵索引；除聚簇索引之外的所有索引都稱為二級(jí)索引（輔助索引）；
• 如果您沒有為表定義PRIMARY KEY，MySQL會(huì)在所有NOT NULL鍵列所在的位置找到第一個(gè)UNIQUE索引，并將其用作聚集索引；
• 如果表沒有索引或沒有合適的UNIQUE索引，則在InnoDB 內(nèi)部生成一個(gè)隱藏的聚集索引
• 二級(jí)索引中的每個(gè)記錄都包含該行的主鍵列以及為二級(jí)索引指定的列；如果主鍵較長，則輔助索引將使用更多空間，因此具有短的主鍵是有利的；

排序索引創(chuàng)建

• 第一階段：將掃描聚簇索引，并生成索引條目并將其添加到排序緩沖區(qū)。當(dāng)排序緩沖區(qū)已滿時(shí)，將對(duì)條目進(jìn)行排序并將其寫到臨時(shí)中間文件中。此過程也稱為“運(yùn)行”；
• 第二階段，將一個(gè)或多個(gè)”運(yùn)行”寫入臨時(shí)中間文件，對(duì)文件中的所有條目執(zhí)行合并排序。
• 第三階段，將已排序的條目插入 B-tree中。

表空間

系統(tǒng)表空間

• 系統(tǒng)表空間是InnoDB數(shù)據(jù)字典，雙寫緩沖區(qū)，更改緩沖區(qū)和撤消日志的存儲(chǔ)區(qū)（ibdata1文件）；

單表文件表空間

• 該文件為每個(gè)表的表空間提供了一種更靈活的選擇，其中，每個(gè)InnoDB表被存儲(chǔ)在其自己的表空間的數(shù)據(jù)文件（.ibd文件），默認(rèn)啟用；

常規(guī)表空間

• 常規(guī)表空間是InnoDB 使用CREATE TABLESPACE語法創(chuàng)建的共享表空間；

撤銷表空間

• 撤消表空間包含撤消日志，其中包含如何通過事務(wù)撤消對(duì)表數(shù)據(jù)更改的信息
• 撤消日志可以存儲(chǔ)在一個(gè)或多個(gè)撤消表空間中。在默認(rèn)配置中，撤消日志位于系統(tǒng)表空間；

臨時(shí)表空間

• 在正常關(guān)閉或初始化中止時(shí)，將刪除臨時(shí)表空間，并在每次啟動(dòng)服務(wù)器時(shí)重新創(chuàng)建

雙寫緩沖區(qū)

[圖片上傳失敗...(image-ceb221-1574387700883)]

• 臟頁數(shù)據(jù)從緩沖池向磁盤寫數(shù)據(jù)時(shí)，在寫到指定磁盤位置前，會(huì)優(yōu)先寫到雙寫緩沖區(qū)；當(dāng)寫到雙寫緩沖區(qū)成功后，才會(huì)向磁盤指定位置寫。
• 如果在頁面寫入過程中發(fā)生操作系統(tǒng)，存儲(chǔ)子系統(tǒng)或mysqld進(jìn)程崩潰，InnoDB以后可以在崩潰恢復(fù)期間從doublewrite緩沖區(qū)中找到該頁面的副本
• 盡管數(shù)據(jù)總是被寫入兩次，但雙寫緩沖區(qū)并不需要兩倍的I / O開銷或兩倍的I / O操作。只需對(duì)操作系統(tǒng)進(jìn)行一次調(diào)用，就可以將數(shù)據(jù)作為一個(gè)較大的順序塊寫入雙寫緩沖區(qū)本身。（解決partial page write問題）
• partial page write問題
  [圖片上傳失敗...(image-58f001-1574387700883)]

重做日志

• 重做日志是基于磁盤的數(shù)據(jù)結(jié)構(gòu)，在崩潰恢復(fù)期間用于糾正不完整事務(wù)寫入的數(shù)據(jù)。
• 以循環(huán)方式寫入重做日志文件ib_logfile0和ib_logfile1，重做日志中的數(shù)據(jù)按照受影響的記錄進(jìn)行編碼；此數(shù)據(jù)統(tǒng)稱為重做。通過重做日志的數(shù)據(jù)傳遞以不斷增加的LSN值表示。

撤銷日志

• 撤消日志是單個(gè)讀寫事務(wù)的撤消記錄的集合
• 撤消日志記錄包含有關(guān)如何撤消事務(wù)對(duì)聚簇索引記錄的最新更改的信息
• 如果另一個(gè)事務(wù)需要將原始數(shù)據(jù)視為一致讀取操作的一部分，則將從撤消日志記錄中檢索未修改的數(shù)據(jù)

其他概念

• 臟頁
  • InnoDB緩沖池中已在內(nèi)存中更新的頁面，其中的更改尚未寫入(刷新)數(shù)據(jù)文件。
• 凈頁
  • InnoDB緩沖池中的一個(gè)頁面，所有內(nèi)存中的更改都被寫入(刷新)數(shù)據(jù)文件。
• 二級(jí)制日志binLog
  • 描述數(shù)據(jù)庫更改（例如表創(chuàng)建操作或表數(shù)據(jù)更改）的“ 事件 ”
  • 包含有關(guān)每個(gè)語句花費(fèi)該更新數(shù)據(jù)多長時(shí)間的信息
  • 二進(jìn)制日志的執(zhí)行順序是在語句執(zhí)行之后但釋放任何鎖之前
  • 當(dāng)使用基于行的二進(jìn)制日志記錄時(shí)，更新是作為行更改而不是SQL語句發(fā)送的
  • 提供了要發(fā)送到從屬服務(wù)器的數(shù)據(jù)更改的記錄
  • 某些數(shù)據(jù)恢復(fù)操作需要使用二進(jìn)制日志
• 通用日志
  • 當(dāng)使用基于行的二進(jìn)制日志記錄時(shí)，更新是作為行更改而不是SQL語句發(fā)送的
  • 常規(guī)查詢?nèi)罩臼莔ysqld在做什么的常規(guī)記錄

總結(jié)

讓我們用sql的執(zhí)行過程，把這些機(jī)制和流程串起來：

• 執(zhí)行DML查詢語句sql1,更改數(shù)據(jù)sql2,提交事務(wù)后再查詢sql3；
• sql1將page存入緩沖池；
• sql2提交事務(wù)之前：
  • 由于數(shù)據(jù)在緩沖池，不論數(shù)據(jù)是否更改二級(jí)索引，均不在緩沖更改區(qū)；
  • 更新緩沖池中數(shù)據(jù)頁（臟頁），是否落磁盤取決于WAL規(guī)則（Write ahead redo log）；
  • 更改page記錄的日志在日志緩沖區(qū)（包含redo log和undo log），是否落磁盤取決于日志緩沖區(qū)大小和刷新策略（默認(rèn)提交事務(wù)立即落磁盤）；
• 事務(wù)提交之后
  • 根據(jù)WAL規(guī)則優(yōu)先寫Redo Log
  • 成功之后；再寫雙寫緩沖區(qū)；
  • 最后寫離散位置的指定page；
• 如果數(shù)據(jù)庫再事務(wù)提交之后崩潰
  • 此時(shí)從redo log中恢復(fù)未完成的事務(wù)（如果Redo Log未寫成功，及事務(wù)未提交成功）；
  • 恢復(fù)日志大致如下：
    • InnoDB自動(dòng)回滾崩潰時(shí)存在的未提交的事務(wù)

InnoDB: Log scan progressed past the checkpoint lsn 369163704
InnoDB: Doing recovery: scanned up to log sequence number 374340608
InnoDB: Doing recovery: scanned up to log sequence number 379583488
InnoDB: Doing recovery: scanned up to log sequence number 384826368
InnoDB: Doing recovery: scanned up to log sequence number 390069248
InnoDB: Doing recovery: scanned up to log sequence number 395312128
InnoDB: Doing recovery: scanned up to log sequence number 400555008

InnoDB: Doing recovery: scanned up to log sequence number 405797888
InnoDB: Doing recovery: scanned up to log sequence number 411040768
InnoDB: Doing recovery: scanned up to log sequence number 414724794
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: 1 transaction(s) which must be rolled back or cleaned up in
total 518425 row operations to undo
InnoDB: Trx id counter is 1792
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59
60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
...
InnoDB: Starting in background the rollback of uncommitted transactions
InnoDB: Rolling back trx with id 1511, 518425 rows to undo
...
InnoDB: Waiting for purge to start
InnoDB: 5.7.18 started; log sequence number 414724794
...
./mysqld: ready for connections.