本篇內(nèi)容主要講解“MySQL事務(wù)日志的特征有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“MySQL事務(wù)日志的特征有哪些”吧!

創(chuàng)新互聯(lián)長期為成百上千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為雨花企業(yè)提供專業(yè)的成都做網(wǎng)站、網(wǎng)站制作，雨花網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

一、MySQL事務(wù)

事務(wù)是MySQL區(qū)別于NOSQL的重要特征，是保證關(guān)系型數(shù)據(jù)庫數(shù)據(jù)一致性的關(guān)鍵技術(shù)。事務(wù)可看作是對數(shù)據(jù)庫操作的基本執(zhí)行單元，可能包含一個或者多個SQL語句。這些語句在執(zhí)行時，要么都執(zhí)行，要么都不執(zhí)行。

事務(wù)的執(zhí)行主要包括兩個操作，提交和回滾。

提交：commit，將事務(wù)執(zhí)行結(jié)果寫入數(shù)據(jù)庫。

回滾：rollback，回滾所有已經(jīng)執(zhí)行的語句，返回修改之前的數(shù)據(jù)。

MySQL事務(wù)包含四個特性，號稱ACID四大天王。

原子性（Atomicity） ：語句要么全執(zhí)行，要么全不執(zhí)行，是事務(wù)最核心的特性，事務(wù)本身就是以原子性來定義的；實現(xiàn)主要基于undo log日志實現(xiàn)的。

持久性（Durability  ：保證事務(wù)提交后不會因為宕機等原因?qū)е聰?shù)據(jù)丟失；實現(xiàn)主要基于redo log日志。

隔離性（Isolation） ：保證事務(wù)執(zhí)行盡可能不受其他事務(wù)影響；InnoDB默認(rèn)的隔離級別是RR，RR的實現(xiàn)主要基于鎖機制、數(shù)據(jù)的隱藏列、undo log和類next-key lock機制。

一致性（Consistency） ：事務(wù)追求的最終目標(biāo)，一致性的實現(xiàn)既需要數(shù)據(jù)庫層面的保障，也需要應(yīng)用層面的保障。

原子性

事務(wù)的原子性就如原子操作一般，表示事務(wù)不可再分，其中的操作要么都做，要么都不做；如果事務(wù)中一個SQL語句執(zhí)行失敗，則已執(zhí)行的語句也必須回滾，數(shù)據(jù)庫退回到事務(wù)前的狀態(tài)。只有0和1，沒有其它值。

事務(wù)的原子性表明事務(wù)就是一個整體，當(dāng)事務(wù)無法成功執(zhí)行的時候，需要將事務(wù)中已經(jīng)執(zhí)行過的語句全部回滾，使得數(shù)據(jù)庫回歸到最初未開始事務(wù)的狀態(tài)。

事務(wù)的原子性就是通過undo log日志進行實現(xiàn)的。當(dāng)事務(wù)需要進行回滾時，InnoDB引擎就會調(diào)用undo log日志進行SQL語句的撤銷，實現(xiàn)數(shù)據(jù)的回滾。

持久性

事務(wù)的持久性是指當(dāng)事務(wù)提交之后，數(shù)據(jù)庫的改變就應(yīng)該是永久性的，而不是暫時的。這也就是說，當(dāng)事務(wù)提交之后，任何其它操作甚至是系統(tǒng)的宕機故障都不會對原來事務(wù)的執(zhí)行結(jié)果產(chǎn)生影響。

事務(wù)的持久性是通過InnoDB存儲引擎中的redo log日志來實現(xiàn)的，具體實現(xiàn)思路見下文。

隔離性

原子性和持久性是單個事務(wù)本身層面的性質(zhì)，而隔離性是指事務(wù)之間應(yīng)該保持的關(guān)系。隔離性要求不同事務(wù)之間的影響是互不干擾的，一個事務(wù)的操作與其它事務(wù)是相互隔離的。

由于事務(wù)可能并不只包含一條SQL語句，所以在事務(wù)的執(zhí)行期間很有可能會有其它事務(wù)開始執(zhí)行。因此多事務(wù)的并發(fā)性就要求事務(wù)之間的操作是相互隔離的。這一點跟多線程之間數(shù)據(jù)同步的概念有些類似。

鎖機制

事務(wù)之間的隔離，是通過鎖機制實現(xiàn)的。當(dāng)一個事務(wù)需要對數(shù)據(jù)庫中的某行數(shù)據(jù)進行修改時，需要先給數(shù)據(jù)加鎖；加了鎖的數(shù)據(jù)，其它事務(wù)是不運行操作的，只能等待當(dāng)前事務(wù)提交或回滾將鎖釋放。

鎖機制并不是一個陌生的概念，在許多場景中都會利用到不同實現(xiàn)的鎖對數(shù)據(jù)進行保護和同步。而在MySQL中，根據(jù)不同的劃分標(biāo)準(zhǔn)，還可將鎖分為不同的種類。

按照粒度劃分：行鎖、表鎖、頁鎖

按照使用方式劃分：共享鎖、排它鎖

按照思想劃分：悲觀鎖、樂觀鎖

鎖機制的知識點很多，由于篇幅不好全部展開講。這里對按照粒度劃分的鎖進行簡單介紹。

粒度：指數(shù)據(jù)倉庫的數(shù)據(jù)單位中保存數(shù)據(jù)的細(xì)化或綜合程度的級別。細(xì)化程度越高，粒度級就越??；相反，細(xì)化程度越低，粒度級就越大。

MySQL按照鎖的粒度劃分可以分為行鎖、表鎖和頁鎖。

行鎖：粒度最小的鎖，表示只針對當(dāng)前操作的行進行加鎖；

表鎖：粒度最大的鎖，表示當(dāng)前的操作對整張表加鎖；

頁鎖：粒度介于行級鎖和表級鎖中間的一種鎖，表示對頁進行加鎖。

數(shù)據(jù)庫的粒度劃分

這三種鎖是在不同層次上對數(shù)據(jù)進行鎖定，由于粒度的不同，其帶來的好處和劣勢也不一而同。

表鎖在操作數(shù)據(jù)時會鎖定整張表，因而并發(fā)性能較差；

行鎖則只鎖定需要操作的數(shù)據(jù)，并發(fā)性能好。但是由于加鎖本身需要消耗資源(獲得鎖、檢查鎖、釋放鎖等都需要消耗資源)，因此在鎖定數(shù)據(jù)較多情況下使用表鎖可以節(jié)省大量資源。

MySQL中不同的存儲引擎能夠支持的鎖也是不一樣的。MyIsam只支持表鎖，而InnoDB同時支持表鎖和行鎖，且出于性能考慮，絕大多數(shù)情況下使用的都是行鎖。

并發(fā)讀寫問題

在并發(fā)情況下，MySQL的同時讀寫可能會導(dǎo)致三類問題，臟讀、不可重復(fù)度和幻讀。

（1）臟讀：當(dāng)前事務(wù)中讀到其他事務(wù)未提交的數(shù)據(jù)，也就是臟數(shù)據(jù)。

以上圖為例，事務(wù)A在讀取文章的閱讀量時，讀取到了事務(wù)B為提交的數(shù)據(jù)。如果事務(wù)B最后沒有順利提交，導(dǎo)致事務(wù)回滾，那么實際上閱讀量并沒有修改成功，而事務(wù)A卻是讀到的修改后的值，顯然不合情理。

（2）不可重復(fù)讀：在事務(wù)A中先后兩次讀取同一個數(shù)據(jù)，但是兩次讀取的結(jié)果不一樣。臟讀與不可重復(fù)讀的區(qū)別在于：前者讀到的是其他事務(wù)未提交的數(shù)據(jù)，后者讀到的是其他事務(wù)已提交的數(shù)據(jù)。

以上圖為例，事務(wù)A在先后讀取文章閱讀量的數(shù)據(jù)時，結(jié)果卻不一樣。說明事務(wù)A在執(zhí)行的過程中，閱讀量的值被其它事務(wù)給修改了。這樣使得數(shù)據(jù)的查詢結(jié)果不再可靠，同樣也不合實際。

（3）幻讀：在事務(wù)A中按照某個條件先后兩次查詢數(shù)據(jù)庫，兩次查詢結(jié)果的行數(shù)不同，這種現(xiàn)象稱為幻讀。不可重復(fù)讀與幻讀的區(qū)別可以通俗的理解為：前者是數(shù)據(jù)變了，后者是數(shù)據(jù)的行數(shù)變了。

以上圖為例，當(dāng)對0<閱讀量<100的文章進行查詢時，先查到了一個結(jié)果，后來查詢到了兩個結(jié)果。這表明同一個事務(wù)的查詢結(jié)果數(shù)不一，行數(shù)不一致。這樣的問題使得在根據(jù)某些條件對數(shù)據(jù)篩選的時候，前后篩選結(jié)果不具有可靠性。

隔離級別

根據(jù)上面這三種問題，產(chǎn)生了四種隔離級別，表明數(shù)據(jù)庫不同程度的隔離性質(zhì)。

在實際的數(shù)據(jù)庫設(shè)計中，隔離級別越高，導(dǎo)致數(shù)據(jù)庫的并發(fā)效率會越低；而隔離級別太低，又會導(dǎo)致數(shù)據(jù)庫在讀寫過程中會遇到各種亂七八糟的問題。

因此在大多數(shù)數(shù)據(jù)庫系統(tǒng)中，默認(rèn)的隔離級別時讀已提交（如Oracle）或者可重復(fù)讀RR（MySQL的InnoDB引擎）。

MVCC

又是一個難嚼的大塊頭。MVCC就是用來實現(xiàn)上面的第三個隔離級別，可重復(fù)讀RR。

MVCC：Multi-Version Concurrency Control，即多版本的并發(fā)控制協(xié)議。

MVCC的特點就是在同一時刻，不同事務(wù)可以讀取到不同版本的數(shù)據(jù)，從而可以解決臟讀和不可重復(fù)讀的問題。

MVCC實際上就是通過數(shù)據(jù)的隱藏列和回滾日志（undo log），實現(xiàn)多個版本數(shù)據(jù)的共存。這樣的好處是，使用MVCC進行讀數(shù)據(jù)的時候，不用加鎖，從而避免了同時讀寫的沖突。

在實現(xiàn)MVCC時，每一行的數(shù)據(jù)中會額外保存幾個隱藏的列，比如當(dāng)前行創(chuàng)建時的版本號和刪除時間和指向undo log的回滾指針。這里的版本號并不是實際的時間值，而是系統(tǒng)版本號。每開始新的事務(wù)，系統(tǒng)版本號都會自動遞增。事務(wù)開始時的系統(tǒng)版本號會作為事務(wù)的版本號，用來和查詢每行記錄的版本號進行比較。

每個事務(wù)又有自己的版本號，這樣事務(wù)內(nèi)執(zhí)行數(shù)據(jù)操作時，就通過版本號的比較來達到數(shù)據(jù)版本控制的目的。

另外，InnoDB實現(xiàn)的隔離級別RR時可以避免幻讀現(xiàn)象的，這是通過next-key lock機制實現(xiàn)的。

next-key lock實際上就是行鎖的一種，只不過它不只是會鎖住當(dāng)前行記錄的本身，還會鎖定一個范圍。比如上面幻讀的例子，開始查詢0<閱讀量<100的文章時，只查到了一個結(jié)果。next-key lock會將查詢出的這一行進行鎖定，同時還會對0<閱讀量<100這個范圍進行加鎖，這實際上是一種間隙鎖。間隙鎖能夠防止其他事務(wù)在這個間隙修改或者插入記錄。這樣一來，就保證了在0<閱讀量<100這個間隙中，只存在原來的一行數(shù)據(jù)，從而避免了幻讀。

間隙鎖：封鎖索引記錄中的間隔

雖然InnoDB使用next-key lock能夠避免幻讀問題，但卻并不是真正的可串行化隔離。再來看一個例子吧。

首先提一個問題：

在T6時間，事務(wù)A提交事務(wù)之后，猜一猜文章A和文章B的閱讀量為多少？

答案是，文章AB的閱讀量都被修改成了10000。這代表著事務(wù)B的提交實際上對事務(wù)A的執(zhí)行產(chǎn)生了影響，表明兩個事務(wù)之間并不是完全隔離的。雖然能夠避免幻讀現(xiàn)象，但是卻沒有達到可串行化的級別。

這還說明，避免臟讀、不可重復(fù)讀和幻讀，是達到可串行化的隔離級別的必要不充分條件?？纱谢嵌寄軌虮苊馀K讀、不可重復(fù)讀和幻讀，但是避免臟讀、不可重復(fù)讀和幻讀卻不一定達到了可串行化。

一致性

一致性是指事務(wù)執(zhí)行結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞，事務(wù)執(zhí)行的前后都是合法的數(shù)據(jù)狀態(tài)。

一致性是事務(wù)追求的最終目標(biāo)，原子性、持久性和隔離性，實際上都是為了保證數(shù)據(jù)庫狀態(tài)的一致性而存在的。

這就不多說了吧。你細(xì)品。

二、MySQL日志系統(tǒng)

了解完MySQL的基本架構(gòu)，大體上能夠?qū)ySQL的執(zhí)行流程有了比較清晰的認(rèn)知。接下來我將為大家介紹一下日志系統(tǒng)。

MySQL日志系統(tǒng)是數(shù)據(jù)庫的重要組件，用于記錄數(shù)據(jù)庫的更新和修改。若數(shù)據(jù)庫發(fā)生故障，可通過不同日志記錄恢復(fù)數(shù)據(jù)庫的原來數(shù)據(jù)。因此實際上日志系統(tǒng)直接決定著MySQL運行的魯棒性和穩(wěn)健性。

MySQL的日志有很多種，如二進制日志（binlog）、錯誤日志、查詢?nèi)罩?、慢查詢?nèi)罩镜?，此外InnoDB存儲引擎還提供了兩種日志：redo log（重做日志）和undo log（回滾日志）。這里將重點針對InnoDB引擎，對重做日志、回滾日志和二進制日志這三種進行分析。

重做日志（redo log）

重做日志（redo log）是InnoDB引擎層的日志，用來記錄事務(wù)操作引起數(shù)據(jù)的變化，記錄的是數(shù)據(jù)頁的物理修改。

重做日記的作用其實很好理解，我打個比方。數(shù)據(jù)庫中數(shù)據(jù)的修改就好比你寫的論文，萬一哪天論文丟了怎么呢？以防這種不幸的發(fā)生，我們可以在寫論文的時候，每一次修改都拿個小本本記錄一下，記錄什么時間對某一頁進行了怎么樣的修改。這就是重做日志。

InnoDB引擎對數(shù)據(jù)的更新，是先將更新記錄寫入redo log日志，然后會在系統(tǒng)空閑的時候或者是按照設(shè)定的更新策略再將日志中的內(nèi)容更新到磁盤之中。這就是所謂的預(yù)寫式技術(shù)（Write Ahead logging）。這種技術(shù)可以大大減少IO操作的頻率，提升數(shù)據(jù)刷新的效率。

臟數(shù)據(jù)刷盤

值得注意的是，redo log日志的大小是固定的，為了能夠持續(xù)不斷的對更新記錄進行寫入，在redo log日志中設(shè)置了兩個標(biāo)志位置，checkpoint和write_pos，分別表示記錄擦除的位置和記錄寫入的位置。redo log日志的數(shù)據(jù)寫入示意圖可見下圖。

當(dāng)write_pos標(biāo)志到了日志結(jié)尾時，會從結(jié)尾跳至日志頭部進行重新循環(huán)寫入。所以redo log的邏輯結(jié)構(gòu)并不是線性的，而是可看作一個圓周運動。write_pos與checkpoint中間的空間可用于寫入新數(shù)據(jù)，寫入和擦除都是往后推移，循環(huán)往復(fù)的。

當(dāng)write_pos追上checkpoint時，表示redo log日志已經(jīng)寫滿。這時不能繼續(xù)執(zhí)行新的數(shù)據(jù)庫更新語句，需要停下來先刪除一些記錄，執(zhí)行checkpoint規(guī)則騰出可寫空間。

checkpoint規(guī)則：checkpoint觸發(fā)后，將buffer中臟數(shù)據(jù)頁和臟日志頁都刷到磁盤。

臟數(shù)據(jù)：指內(nèi)存中未刷到磁盤的數(shù)據(jù)。

redo log中最重要的概念就是緩沖池buffer pool，這是在內(nèi)存中分配的一個區(qū)域，包含了磁盤中部分?jǐn)?shù)據(jù)頁的映射，作為訪問數(shù)據(jù)庫的緩沖。

當(dāng)請求讀取數(shù)據(jù)時，會先判斷是否在緩沖池命中，如果未命中才會在磁盤上進行檢索后放入緩沖池；

當(dāng)請求寫入數(shù)據(jù)時，會先寫入緩沖池，緩沖池中修改的數(shù)據(jù)會定期刷新到磁盤中。這一過程也被稱之為刷臟 。

因此，當(dāng)數(shù)據(jù)修改時，除了修改buffer pool中的數(shù)據(jù)，還會在redo log中記錄這次操作；當(dāng)事務(wù)提交時，會根據(jù)redo log的記錄對數(shù)據(jù)進行刷盤。如果MySQL宕機，重啟時可以讀取redo log中的數(shù)據(jù)，對數(shù)據(jù)庫進行恢復(fù)，從而保證了事務(wù)的持久性，使得數(shù)據(jù)庫獲得crash-safe能力。

臟日志刷盤

除了上面提到的對于臟數(shù)據(jù)的刷盤，實際上redo log日志在記錄時，為了保證日志文件的持久化，也需要經(jīng)歷將日志記錄從內(nèi)存寫入到磁盤的過程。redo log日志可分為兩個部分，一是存在易失性內(nèi)存中的緩存日志redo log buff，二是保存在磁盤上的redo log日志文件redo log file。

為了確保每次記錄都能夠?qū)懭氲酱疟P中的日志中，每次將redo log buffer中的日志寫入redo log file的過程中都會調(diào)用一次操作系統(tǒng)的fsync操作。

fsync函數(shù)：包含在UNIX系統(tǒng)頭文件#include 中，用于同步內(nèi)存中所有已修改的文件數(shù)據(jù)到儲存設(shè)備。

在寫入的過程中，還需要經(jīng)過操作系統(tǒng)內(nèi)核空間的os buffer。redo log日志的寫入過程可見下圖。

redo log日志刷盤流程

二進制日志（binlog）

二進制日志binlog是服務(wù)層的日志，還被稱為歸檔日志。binlog主要記錄數(shù)據(jù)庫的變化情況，內(nèi)容包括數(shù)據(jù)庫所有的更新操作。所有涉及數(shù)據(jù)變動的操作，都要記錄進二進制日志中。因此有了binlog可以很方便的對數(shù)據(jù)進行復(fù)制和備份，因而也常用作主從庫的同步。

這里binlog所存儲的內(nèi)容看起來似乎與redo log很相似，但是其實不然。redo log是一種物理日志，記錄的是實際上對某個數(shù)據(jù)進行了怎么樣的修改；而binlog是邏輯日志，記錄的是SQL語句的原始邏輯，比如”給ID=2這一行的a字段加1 "。binlog日志中的內(nèi)容是二進制的，根據(jù)日記格式參數(shù)的不同，可能基于SQL語句、基于數(shù)據(jù)本身或者二者的混合。一般常用記錄的都是SQL語句。

這里的物理和邏輯的概念，我的個人理解是：

物理的日志可看作是實際數(shù)據(jù)庫中數(shù)據(jù)頁上的變化信息，只看重結(jié)果，而不在乎是通過“何種途徑”導(dǎo)致了這種結(jié)果；

邏輯的日志可看作是通過了某一種方法或者操作手段導(dǎo)致數(shù)據(jù)發(fā)生了變化，存儲的是邏輯性的操作。

同時，redo log是基于crash recovery，保證MySQL宕機后的數(shù)據(jù)恢復(fù)；而binlog是基于point-in-time recovery，保證服務(wù)器可以基于時間點對數(shù)據(jù)進行恢復(fù)，或者對數(shù)據(jù)進行備份。

事實上最開始MySQL是沒有redo log日志的。因為起先MySQL是沒有InnoDB引擎的，自帶的引擎是MyISAM。binlog是服務(wù)層的日志，因此所有引擎都能夠使用。但是光靠binlog日志只能提供歸檔的作用，無法提供crash-safe能力，所以InnoDB引擎就采用了學(xué)自于Oracle的技術(shù)，也就是redo log，這才擁有了crash-safe能力。這里對redo log日志和binlog日志的特點分別進行了對比：

redo log與binlog的特點比較

在MySQL執(zhí)行更新語句時，都會涉及到redo log日志和binlog日志的讀寫。一條更新語句的執(zhí)行過程如下：

MySQL更新語句的執(zhí)行過程

從上圖可以看出，MySQL在執(zhí)行更新語句的時候，在服務(wù)層進行語句的解析和執(zhí)行，在引擎層進行數(shù)據(jù)的提取和存儲；同時在服務(wù)層對binlog進行寫入，在InnoDB內(nèi)進行redo log的寫入。

不僅如此，在對redo log寫入時有兩個階段的提交，一是binlog寫入之前prepare狀態(tài)的寫入，二是binlog寫入之后commit狀態(tài)的寫入。

之所以要安排這么一個兩階段提交，自然是有它的道理的?，F(xiàn)在我們可以假設(shè)不采用兩階段提交的方式，而是采用“單階段”進行提交，即要么先寫入redo log，后寫入binlog；要么先寫入binlog，后寫入redo log。這兩種方式的提交都會導(dǎo)致原先數(shù)據(jù)庫的狀態(tài)和被恢復(fù)后的數(shù)據(jù)庫的狀態(tài)不一致。

先寫入redo log，后寫入binlog：

在寫完redo log之后，數(shù)據(jù)此時具有crash-safe能力，因此系統(tǒng)崩潰，數(shù)據(jù)會恢復(fù)成事務(wù)開始之前的狀態(tài)。但是，若在redo log寫完時候，binlog寫入之前，系統(tǒng)發(fā)生了宕機。此時binlog沒有對上面的更新語句進行保存，導(dǎo)致當(dāng)使用binlog進行數(shù)據(jù)庫的備份或者恢復(fù)時，就少了上述的更新語句。從而使得id=2這一行的數(shù)據(jù)沒有被更新。

先寫redo log后寫binlog的問題

先寫入binlog，后寫入redo log：

寫完binlog之后，所有的語句都被保存，所以通過binlog復(fù)制或恢復(fù)出來的數(shù)據(jù)庫中id=2這一行的數(shù)據(jù)會被更新為a=1。但是如果在redo log寫入之前，系統(tǒng)崩潰，那么redo log中記錄的這個事務(wù)會無效，導(dǎo)致實際數(shù)據(jù)庫中id=2這一行的數(shù)據(jù)并沒有更新。

先寫binlog后寫redo log的問題

由此可見，兩階段的提交就是為了避免上述的問題，使得binlog和redo log中保存的信息是一致的。

回滾日志（undo log）

回滾日志同樣也是InnoDB引擎提供的日志，顧名思義，回滾日志的作用就是對數(shù)據(jù)進行回滾。當(dāng)事務(wù)對數(shù)據(jù)庫進行修改，InnoDB引擎不僅會記錄redo log，還會生成對應(yīng)的undo log日志；如果事務(wù)執(zhí)行失敗或調(diào)用了rollback，導(dǎo)致事務(wù)需要回滾，就可以利用undo log中的信息將數(shù)據(jù)回滾到修改之前的樣子。

但是undo log不redo log不一樣，它屬于邏輯日志。它對SQL語句執(zhí)行相關(guān)的信息進行記錄。當(dāng)發(fā)生回滾時，InnoDB引擎會根據(jù)undo log日志中的記錄做與之前相反的工作。比如對于每個數(shù)據(jù)插入操作（insert），回滾時會執(zhí)行數(shù)據(jù)刪除操作（delete）；對于每個數(shù)據(jù)刪除操作（delete），回滾時會執(zhí)行數(shù)據(jù)插入操作（insert）；對于每個數(shù)據(jù)更新操作（update），回滾時會執(zhí)行一個相反的數(shù)據(jù)更新操作（update），把數(shù)據(jù)改回去。undo log由兩個作用，一是提供回滾，二是實現(xiàn)MVCC。

三、主從復(fù)制

主從復(fù)制的概念很簡單，就是從原來的數(shù)據(jù)庫復(fù)制一個完全一樣的數(shù)據(jù)庫，原來的數(shù)據(jù)庫稱作主數(shù)據(jù)庫，復(fù)制的數(shù)據(jù)庫稱為從數(shù)據(jù)庫。從數(shù)據(jù)庫會與主數(shù)據(jù)庫進行數(shù)據(jù)同步，保持二者的數(shù)據(jù)一致性。

主從復(fù)制的原理實際上就是通過bin log日志實現(xiàn)的。bin log日志中保存了數(shù)據(jù)庫中所有SQL語句，通過對bin log日志中SQL的復(fù)制，然后再進行語句的執(zhí)行即可實現(xiàn)從數(shù)據(jù)庫與主數(shù)據(jù)庫的同步。

主從復(fù)制的過程可見下圖。主從復(fù)制的過程主要是靠三個線程進行的，一個運行在主服務(wù)器中的發(fā)送線程，用于發(fā)送binlog日志到從服務(wù)器。兩外兩個運行在從服務(wù)器上的I/O線程和SQL線程。I/O線程用于讀取主服務(wù)器發(fā)送過來的binlog日志內(nèi)容，并拷貝到本地的中繼日志中。SQL線程用于讀取中繼日志中關(guān)于數(shù)據(jù)更新的SQL語句并執(zhí)行，從而實現(xiàn)主從庫的數(shù)據(jù)一致。

主從復(fù)制原理

之所以需要實現(xiàn)主從復(fù)制，實際上是由實際應(yīng)用場景所決定的。主從復(fù)制能夠帶來的好處有：

1. 通過復(fù)制實現(xiàn)數(shù)據(jù)的異地備份，當(dāng)主數(shù)據(jù)庫故障時，可切換從數(shù)據(jù)庫，避免數(shù)據(jù)丟失。

2. 可實現(xiàn)架構(gòu)的擴展，當(dāng)業(yè)務(wù)量越來越大，I/O訪問頻率過高時，采用多庫的存儲，可以降低磁盤I/O訪問的頻率，提高單個機器的I/O性能。

3. 可實現(xiàn)讀寫分離，使數(shù)據(jù)庫能支持更大的并發(fā)。

4. 實現(xiàn)服務(wù)器的負(fù)載均衡，通過在主服務(wù)器和從服務(wù)器之間切分處理客戶查詢的負(fù)荷。

到此，相信大家對“MySQL事務(wù)日志的特征有哪些”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！