(資料圖)
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文檔上的豐富操作
關鍵詞：
