(資料圖)

1.事務(wù)日志

1.1.事務(wù)日志有助于提高事務(wù)的效率

1.1.2.更改的記錄寫入事務(wù)日志中，事務(wù)日志會被持久化保存在硬盤上

1.2.事務(wù)日志采用的是追加寫操作，是在硬盤中一小塊區(qū)域內(nèi)的順序I/O，而不是需要寫多個地方的隨機(jī)I/O，所以寫入事務(wù)日志是一種相對較快的操作

1.3.大多數(shù)使用這種技術(shù)（write-ahead logging，預(yù)寫式日志）的存儲引擎修改數(shù)據(jù)最終需要寫入磁盤兩次

1.4.如果修改操作已經(jīng)寫入事務(wù)日志，那么即使系統(tǒng)在數(shù)據(jù)本身寫入硬盤之前發(fā)生崩潰，存儲引擎仍可在重新啟動時恢復(fù)更改

2.MySQL中的事務(wù)

2.1.自動提交模式

2.1.1.AUTOCOMMIT

2.1.2.通過禁用此模式，可以在事務(wù)中執(zhí)行一系列語句，并在結(jié)束時執(zhí)行COMMIT提交事務(wù)或ROLLBACK回滾事務(wù)

2.2.可以使用SET命令設(shè)置AUTOCOMMIT變量來啟用或禁用自動提交模式

2.2.1.啟用可以設(shè)置為1或者ON

2.2.2.禁用可以設(shè)置為0或者OFF

2.3.AUTOCOMMIT=0，則當(dāng)前連接總是會處于某個事務(wù)中，直到發(fā)出COMMIT或者ROLLBACK，然后MySQL會立即啟動一個新的事務(wù)

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

2.5.執(zhí)行SET TRANSACTION ISOLATION LEVEL命令來設(shè)置隔離級別

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

2.5.2.最好在服務(wù)器級別設(shè)置最常用的隔離，并且只在顯式情況下修改

2.6.MySQL不在服務(wù)器層管理事務(wù)，事務(wù)是由下層的存儲引擎實現(xiàn)的

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

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

2.6.3.在非事務(wù)表中執(zhí)行事務(wù)相關(guān)操作的時候，MySQL通常不會發(fā)出提醒，也不會報錯

2.6.4.最好不要在應(yīng)用程序中混合使用存儲引擎

2.6.4.1.失敗的事務(wù)可能導(dǎo)致不一致的結(jié)果，因為某些部分可以回滾，而其他部分不能回滾

2.7.InnoDB使用兩階段鎖定協(xié)議

2.7.1.two-phase locking protocol

2.7.2.在事務(wù)執(zhí)行期間，隨時都可以獲取鎖

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

2.8.InnoDB還支持通過特定的語句進(jìn)行顯式鎖定

2.8.1.不屬于SQL規(guī)范

2.9.支持LOCK TABLES和UNLOCK TABLES命令，這些命令在服務(wù)器級別而不在存儲引擎中實現(xiàn)

2.10.應(yīng)該使用支持事務(wù)的存儲引擎

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

3.多版本并發(fā)控制

3.1.MVCC

3.2.行級鎖的一個變種

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

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

3.3.Undo日志寫入是服務(wù)器崩潰恢復(fù)過程的一部分，并且是事務(wù)性的

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

3.3.2.Redo日志和Undo日志的大小也是高并發(fā)事務(wù)工作機(jī)制中的重要影響因素

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

3.5.READ UNCOMMITTED與MVCC不兼容

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

3.6.SERIALIZABLE與MVCC也不兼容

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

4.復(fù)制

4.1.一種原生方式來將一個節(jié)點執(zhí)行的寫操作分發(fā)到其他節(jié)點

4.2.對于在生產(chǎn)環(huán)境中運(yùn)行的任何數(shù)據(jù)，都應(yīng)該使用復(fù)制并至少有三個以上的副本

4.3.理想情況下應(yīng)該分布在不同的地區(qū)（在云托管環(huán)境中，稱為region）用于災(zāi)難恢復(fù)計劃

5.數(shù)據(jù)文件結(jié)構(gòu)

5.1.在8.0版本中

5.1.1.將表的元數(shù)據(jù)重新設(shè)計為一種數(shù)據(jù)字典

5.1.1.1.在表的.ibd文件中

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

5.1.2.刪除了基于文件的表元數(shù)據(jù)存儲

5.2.引入了字典對象緩存

5.2.1.基于最近最少使用（LRU）的內(nèi)存緩存

5.2.1.1.分區(qū)定義

5.2.1.2.表定義

5.2.1.3.存儲程序定義

5.2.1.4.字符集

5.2.1.5.排序信息

5.2.2.當(dāng)前訪問最活躍的那些表，在緩存中最常出現(xiàn)

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

5.3.原子DDL

5.3.1.MySQL 8.0引入了原子數(shù)據(jù)定義更改

5.3.2.數(shù)據(jù)定義語句現(xiàn)在要么全部成功完成，要么全部失敗回滾

6.InnoDB引擎

6.1.MySQL主要的改進(jìn)核心在于InnoDB的演進(jìn)

6.1.1.表元數(shù)據(jù)、用戶認(rèn)證、身份鑒權(quán)這些內(nèi)部統(tǒng)計信息的管理也已經(jīng)調(diào)整為使用InnoDB表來實現(xiàn)

6.2.MySQL的默認(rèn)事務(wù)型存儲引擎

6.2.1.現(xiàn)在已經(jīng)成為金標(biāo)準(zhǔn)，是推薦使用的引擎

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

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

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

6.3.最佳實踐是使用InnoDB存儲引擎作為所有應(yīng)用程序的默認(rèn)引擎

6.4.將數(shù)據(jù)存儲在一系列的數(shù)據(jù)文件中，這些文件統(tǒng)被稱為表空間（tablespace）

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

6.5.使用MVCC來實現(xiàn)高并發(fā)性，并實現(xiàn)了所有4個SQL標(biāo)準(zhǔn)隔離級別

6.5.1.默認(rèn)為REPEATABLE READ隔離級別

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

6.5.2.1.不只鎖定在查詢中涉及的行，還會對索引結(jié)構(gòu)中的間隙進(jìn)行鎖定，以防止幻行被插入

6.6.InnoDB表是基于聚簇索引構(gòu)建的

6.6.1.聚簇索引提供了非?？焖俚闹麈I查找

6.7.通過一些機(jī)制和工具支持真正的在線“熱”備份

6.7.1.Oracle專有的MySQL Enterprise Backup

6.7.2.開源的Percona XtraBackup

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

關(guān)鍵詞：