(資料圖)

1.事務(wù)日志

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

1.1.1.存儲(chǔ)引擎只需要更改內(nèi)存中的數(shù)據(jù)副本，而不用每次修改磁盤中的表，這會(huì)非常快

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

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

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

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

2.MySQL中的事務(wù)

2.1.自動(dòng)提交模式

2.1.1.AUTOCOMMIT

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

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

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

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

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

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

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

2.5.1.新的隔離級(jí)別會(huì)在下一個(gè)事務(wù)開始的時(shí)候生效

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

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

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

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

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

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

2.6.4.1.失敗的事務(wù)可能導(dǎo)致不一致的結(jié)果，因?yàn)槟承┎糠挚梢曰貪L，而其他部分不能回滾

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

2.7.1.two-phase locking protocol

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

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

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

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

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

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

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

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

3.1.MVCC

3.2.行級(jí)鎖的一個(gè)變種

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

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

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

3.3.1.所有Undo日志寫入也都會(huì)寫入Redo日志

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

3.4.僅適用于REPEATABLE READ和READ COMMITTED隔離級(jí)別

3.5.READ UNCOMMITTED與MVCC不兼容

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

3.6.SERIALIZABLE與MVCC也不兼容

3.6.1.讀取會(huì)鎖定它們返回的每一行

4.復(fù)制

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

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

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

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

5.1.在8.0版本中

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

5.1.1.1.在表的.ibd文件中

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

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

5.2.引入了字典對(duì)象緩存

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

5.2.1.1.分區(qū)定義

5.2.1.2.表定義

5.2.1.3.存儲(chǔ)程序定義

5.2.1.4.字符集

5.2.1.5.排序信息

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

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

5.3.原子DDL

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

5.3.2.數(shù)據(jù)定義語(yǔ)句現(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ì)信息的管理也已經(jīng)調(diào)整為使用InnoDB表來(lái)實(shí)現(xiàn)

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

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

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

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

6.2.4.幾乎能覆蓋每一種使用場(chǎng)景

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

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

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

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

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

6.5.2.通過(guò)間隙鎖（next-key locking）策略來(lái)防止在這個(gè)隔離級(jí)別上的幻讀

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

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

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

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

6.7.1.Oracle專有的MySQL Enterprise Backup

6.7.2.開源的Percona XtraBackup

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

關(guān)鍵詞：