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ù)（例如表定義）的文件墩弯；
• 盡管每個InnoDB表都有一個 .frm文件吩跋，但是InnoDB 在系統(tǒng)表空間中維護(hù)其自己的表元數(shù)據(jù)；

表移動

• 可移動表空間
  • 一個服務(wù)器實(shí)例復(fù)制到另一個服務(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)锌钮；

聚簇索引和二級索引（輔助索引）

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

排序索引創(chuàng)建

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

表空間

系統(tǒng)表空間

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

單表文件表空間

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

常規(guī)表空間

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

撤銷表空間

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

臨時表空間

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

雙寫緩沖區(qū)

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

• 臟頁數(shù)據(jù)從緩沖池向磁盤寫數(shù)據(jù)時鳖敷，在寫到指定磁盤位置前，會優(yōu)先寫到雙寫緩沖區(qū)程拭；當(dāng)寫到雙寫緩沖區(qū)成功后定踱，才會向磁盤指定位置寫。
• 如果在頁面寫入過程中發(fā)生操作系統(tǒng)恃鞋，存儲子系統(tǒng)或mysqld進(jìn)程崩潰崖媚，InnoDB以后可以在崩潰恢復(fù)期間從doublewrite緩沖區(qū)中找到該頁面的副本
• 盡管數(shù)據(jù)總是被寫入兩次，但雙寫緩沖區(qū)并不需要兩倍的I / O開銷或兩倍的I / O操作恤浪。只需對操作系統(tǒng)進(jìn)行一次調(diào)用畅哑，就可以將數(shù)據(jù)作為一個較大的順序塊寫入雙寫緩沖區(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值表示。

撤銷日志

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

其他概念

• 臟頁
  • InnoDB緩沖池中已在內(nèi)存中更新的頁面圾结，其中的更改尚未寫入(刷新)數(shù)據(jù)文件。
• 凈頁
  • InnoDB緩沖池中的一個頁面齿诉，所有內(nèi)存中的更改都被寫入(刷新)數(shù)據(jù)文件筝野。
• 二級制日志binLog
  • 描述數(shù)據(jù)庫更改（例如表創(chuàng)建操作或表數(shù)據(jù)更改）的“ 事件 ”
  • 包含有關(guān)每個語句花費(fèi)該更新數(shù)據(jù)多長時間的信息
  • 二進(jìn)制日志的執(zhí)行順序是在語句執(zhí)行之后但釋放任何鎖之前
  • 當(dāng)使用基于行的二進(jìn)制日志記錄時，更新是作為行更改而不是SQL語句發(fā)送的
  • 提供了要發(fā)送到從屬服務(wù)器的數(shù)據(jù)更改的記錄
  • 某些數(shù)據(jù)恢復(fù)操作需要使用二進(jìn)制日志
• 通用日志
  • 當(dāng)使用基于行的二進(jìn)制日志記錄時粤剧，更新是作為行更改而不是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ù)是否更改二級索引，均不在緩沖更改區(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ù)提交之后崩潰
  • 此時從redo log中恢復(fù)未完成的事務(wù)（如果Redo Log未寫成功，及事務(wù)未提交成功）嗤瞎；
  • 恢復(fù)日志大致如下：
    • InnoDB自動回滾崩潰時存在的未提交的事務(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.