文章來源地址http://www.zghlxwxcb.cn/news/detail-650169.html

1.?事務(wù)日志

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

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

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

1.2.?事務(wù)日志采用的是追加寫操作，是在硬盤中一小塊區(qū)域內(nèi)的順序I/O，而不是需要寫多個地方的隨機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，則當前連接總是會處于某個事務(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還支持通過特定的語句進行顯式鎖定

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ù)工作機制中的重要影響因素

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)境中運行的任何數(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.?當前訪問最活躍的那些表，在緩存中最常出現(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主要的改進核心在于InnoDB的演進

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

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

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

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

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

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

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

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

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

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

6.5.1.?默認為REPEATABLE READ隔離級別

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

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

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

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

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

6.7.1.?Oracle專有的MySQL Enterprise Backup

6.7.2.?開源的Percona XtraBackup

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

到了這里，關(guān)于讀高性能MySQL（第4版）筆記02_MySQL架構(gòu)（下）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！