1. 事務日誌

1.1. 事務日誌有助於提高事務的效率

1.1.1. 存儲引擎只需要更改記憶體中的數據副本，而不用每次修改磁碟中的表，這會非常快

1.1.2. 更改的記錄寫入事務日誌中，事務日誌會被持久化保存在硬碟上

1.2. 事務日誌採用的是追加寫操作，是在硬碟中一小塊區域內的順序I/O，而不是需要寫多個地方的隨機I/O，所以寫入事務日誌是一種相對較快的操作

1.3. 大多數使用這種技術（write-ahead logging，預寫式日誌）的存儲引擎修改數據最終需要寫入磁碟兩次

1.4. 如果修改操作已經寫入事務日誌，那麼即使系統在數據本身寫入硬碟之前發生崩潰，存儲引擎仍可在重新啟動時恢復更改

2. MySQL中的事務

2.1. 自動提交模式

2.1.1. AUTOCOMMIT

2.1.2. 通過禁用此模式，可以在事務中執行一系列語句，併在結束時執行COMMIT提交事務或ROLLBACK回滾事務

2.2. 可以使用SET命令設置AUTOCOMMIT變數來啟用或禁用自動提交模式

2.2.1. 啟用可以設置為1或者ON

2.2.2. 禁用可以設置為0或者OFF

2.3. AUTOCOMMIT=0，則當前連接總是會處於某個事務中，直到發出COMMIT或者ROLLBACK，然後MySQL會立即啟動一個新的事務

2.4. 除了在禁用AUTOCOMMIT的事務中可以使用之外，其他任何時候都不要顯式地執行LOCK TABLES，不管使用的是什麼存儲引擎

2.5. 執行SET TRANSACTION ISOLATION LEVEL命令來設置隔離級別

2.5.1. 新的隔離級別會在下一個事務開始的時候生效

2.5.2. 最好在伺服器級別設置最常用的隔離，並且只在顯式情況下修改

2.6. MySQL不在伺服器層管理事務，事務是由下層的存儲引擎實現的

2.6.1. 在同一個事務中，混合使用多種存儲引擎是不可靠的

2.6.2. 為每張表選擇合適的存儲引擎，並不惜一切代價避免在應用中混合使用存儲引擎是非常重要的

2.6.3. 在非事務表中執行事務相關操作的時候，MySQL通常不會發出提醒，也不會報錯

2.6.4. 最好不要在應用程式中混合使用存儲引擎

2.6.4.1. 失敗的事務可能導致不一致的結果，因為某些部分可以回滾，而其他部分不能回滾

2.7. InnoDB使用兩階段鎖定協議

2.7.1. two-phase locking protocol

2.7.2. 在事務執行期間，隨時都可以獲取鎖

2.7.3. 但鎖只有在提交或回滾後才會釋放，並且所有的鎖會同時釋放

2.8. InnoDB還支持通過特定的語句進行顯式鎖定

2.8.1. 不屬於SQL規範

2.9. 支持LOCK TABLES和UNLOCK TABLES命令，這些命令在伺服器級別而不在存儲引擎中實現

2.10. 應該使用支持事務的存儲引擎

2.10.1. InnoDB支持行級鎖，所以沒必要使用LOCKTABLES

3. 多版本併發控制

3.1. MVCC

3.2. 行級鎖的一個變種

3.2.1. 在很多情況下避免了加鎖操作，因此開銷更低

3.2.2. 不僅實現了非阻塞的讀操作，寫操作也只鎖定必要的行

3.3. Undo日誌寫入是伺服器崩潰恢復過程的一部分，並且是事務性的

3.3.1. 所有Undo日誌寫入也都會寫入Redo日誌

3.3.2. Redo日誌和Undo日誌的大小也是高併發事務工作機制中的重要影響因素

3.4. 僅適用於REPEATABLE READ和READ COMMITTED隔離級別

3.5. READ UNCOMMITTED與MVCC不相容

3.5.1. 查詢不會讀取適合其事務版本的行版本，而是不管怎樣都讀最新版本

3.6. SERIALIZABLE與MVCC也不相容

3.6.1. 讀取會鎖定它們返回的每一行

4. 複製

4.1. 一種原生方式來將一個節點執行的寫操作分發到其他節點

4.2. 對於在生產環境中運行的任何數據，都應該使用複製並至少有三個以上的副本

4.3. 理想情況下應該分佈在不同的地區（在雲托管環境中，稱為region）用於災難恢復計劃

5. 數據文件結構

5.1. 在8.0版本中

5.1.1. 將表的元數據重新設計為一種數據字典

5.1.1.1. 在表的.ibd文件中

5.1.1.2. 減少了I/O，非常高效

5.1.2. 刪除了基於文件的表元數據存儲

5.2. 引入了字典對象緩存

5.2.1. 基於最近最少使用（LRU）的記憶體緩存

5.2.1.1. 分區定義

5.2.1.2. 表定義

5.2.1.3. 存儲程式定義

5.2.1.4. 字元集

5.2.1.5. 排序信息

5.2.2. 當前訪問最活躍的那些表，在緩存中最常出現

5.2.2.1. 每個表的.ibd和.frm文件被替換為已經被序列化的字典信息（.sdi）

5.3. 原子DDL

5.3.1. MySQL 8.0引入了原子數據定義更改

5.3.2. 數據定義語句現在要麼全部成功完成，要麼全部失敗回滾

6. InnoDB引擎

6.1. MySQL主要的改進核心在於InnoDB的演進

6.1.1. 表元數據、用戶認證、身份鑒權這些內部統計信息的管理也已經調整為使用InnoDB表來實現

6.2. MySQL的預設事務型存儲引擎

6.2.1. 現在已經成為金標準，是推薦使用的引擎

6.2.2. 最重要、使用最廣泛的引擎

6.2.3. 為處理大量短期事務而設計的，這些事務通常是正常提交的，很少會被回滾

6.2.4. 幾乎能覆蓋每一種使用場景

6.3. 最佳實踐是使用InnoDB存儲引擎作為所有應用程式的預設引擎

6.4. 將數據存儲在一系列的數據文件中，這些文件統被稱為表空間（tablespace）

6.4.1. 表空間本質上是一個由InnoDB自己管理的黑盒

6.5. 使用MVCC來實現高併發性，並實現了所有4個SQL標準隔離級別

6.5.1. 預設為REPEATABLE READ隔離級別

6.5.2. 通過間隙鎖（next-key locking）策略來防止在這個隔離級別上的幻讀

6.5.2.1. 不只鎖定在查詢中涉及的行，還會對索引結構中的間隙進行鎖定，以防止幻行被插入

6.6. InnoDB表是基於聚簇索引構建的

6.6.1. 聚簇索引提供了非常快速的主鍵查找

6.7. 通過一些機制和工具支持真正的線上“熱”備份

6.7.1. Oracle專有的MySQL Enterprise Backup

6.7.2. 開源的Percona XtraBackup

6.8. 引入了SQL函數來支持在JSON文檔上的豐富操作