《《MySQL運(yùn)維內(nèi)參》節(jié)選》要點(diǎn)：
本文介紹了《MySQL運(yùn)維內(nèi)參》節(jié)選，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

前面幾篇連載講述了Buffer Pool以及日志的基礎(chǔ)內(nèi)容,接下來(lái),講述的是基于日志的想象,理解,以及它的存儲(chǔ)格式.

日志的意義在哪里?

上面已經(jīng)講述過,日志是在邏輯事務(wù)對(duì)數(shù)據(jù)庫(kù)做DML操作時(shí),其所包含的物理事務(wù)MTR所記錄的針對(duì)所有涉及到的Buffer Pool頁(yè)面的修改記錄.

為了更好的講述日志的意義,這里通過下面幾個(gè)方面來(lái)更好的說(shuō)明.

假如沒有寫日志

假如沒有寫日志,那數(shù)據(jù)庫(kù)在做了任何修改之后,必須要直接將Buffer Page刷磁盤,不然如果此時(shí)數(shù)據(jù)庫(kù)掛了,即使事務(wù)被提交了,這些修改還是沒法恢復(fù).這將帶來(lái)的災(zāi)難是,IO大量增加,這個(gè)時(shí)候的數(shù)據(jù)庫(kù),相當(dāng)于是一個(gè)簡(jiǎn)單的文件系統(tǒng),無(wú)論寫什么數(shù)據(jù),都必須馬上刷入磁盤,Buffer Pool的作用可能只是一個(gè)用來(lái)修改文件頁(yè)面的臨時(shí)緩存而已.

假如沒有寫日志,在數(shù)據(jù)庫(kù)做了DML操作之后,數(shù)據(jù)庫(kù)可能在事務(wù)沒有提交時(shí)就將Buffer Page刷到磁盤了,但此時(shí)需要回滾,而我們知道,回滾段的內(nèi)容也是通過Buffer Pool管理的,它的每個(gè)頁(yè)和B樹頁(yè)面是一樣的,只是作用不一樣而已,由此可知,回滾段數(shù)據(jù)也是通過REDO日志來(lái)保證完整性的.那么如果沒有了日志,Buffer Page中的回滾段頁(yè)面也需要直接寫入,沒有了任何緩存,性能會(huì)非常低.

假如沒有寫日志,數(shù)據(jù)庫(kù)在關(guān)閉(掛掉)后再啟動(dòng)時(shí),就不需要做REDO操作了(因?yàn)闆]有寫日志),但需要做UNDO操作,因?yàn)閁NDO不是通過REDO來(lái)恢復(fù)的,而是自己寫入了(假設(shè)每次寫B(tài)uffer Page之后都直接刷盤了),所以回滾段是有效的,還可以讓沒有提交的事務(wù)回滾掉(因?yàn)槿绻粋€(gè)事務(wù)修改的頁(yè)面很多的話,肯定會(huì)有一部分頁(yè)面先刷掉的,所以有可能需要回滾),勉強(qiáng)還可以保證數(shù)據(jù)庫(kù)的完整性.

綜合上面的假設(shè),現(xiàn)在已經(jīng)明白,日志的作用就是用來(lái)保證Buffer Pool頁(yè)面的數(shù)據(jù)寫入不丟失,反過來(lái)說(shuō),如果每個(gè)Buffer Pool中的Page每次都刷入到磁盤了,這樣就不需要REDO日志了,此時(shí)這個(gè)數(shù)據(jù)庫(kù)就是一個(gè)文件系統(tǒng)了,因?yàn)锽uffer Pool每次都刷,相當(dāng)于每次寫完直接寫文件.所以說(shuō),日志,是數(shù)據(jù)庫(kù)管理系統(tǒng)與文件系統(tǒng)的最核心的區(qū)別.

所以如果沒有日志,數(shù)據(jù)庫(kù)的性能就低到完全沒法用了,因?yàn)镮O太大了,同時(shí),這種IO操作都是隨機(jī)寫入,很容易導(dǎo)致IO到達(dá)瓶頸,所以為了提高數(shù)據(jù)庫(kù)性能,就必須要使用到REDO日志機(jī)制.

使用日志能提高性能的關(guān)鍵原因,有以下三方面：

1. 因?yàn)槿罩臼怯脕?lái)記錄Buffer Pool中Page的修改記錄的,把對(duì)Page的寫入轉(zhuǎn)化為對(duì)日志的寫入,那此時(shí)Page就不需要每次都刷盤,寫Page頁(yè)面只需要在內(nèi)存中寫入即可,性能會(huì)非常好.

2. 通常,一個(gè)頁(yè)面是16K,如果不寫日志的話,每次的寫入單位還是16K,即使修改很少量的數(shù)據(jù),也是如此,這樣會(huì)導(dǎo)致無(wú)效IO非常嚴(yán)重,反過來(lái)說(shuō),也只有通過日志機(jī)制,才能真正體現(xiàn)出真實(shí)寫入的數(shù)據(jù)量,不會(huì)存在對(duì)IO的浪費(fèi),Page的刷盤數(shù)量會(huì)大大減少.

3. 如果沒有日志就會(huì)每次都刷Page,而這些Page的相對(duì)位置是亂的,并不是順序的,刷盤大多都是隨機(jī)IO,這對(duì)于機(jī)械硬盤,性能是非常差的,而有了日志,巧妙的將隨機(jī)IO轉(zhuǎn)化成了日志的順序IO,這將大大的提高IOPS,性能會(huì)非常好.

日志文件大小區(qū)別

使用日志對(duì)數(shù)據(jù)庫(kù)的性能有很大的影響,那日志還有什么其它的因素會(huì)影響數(shù)據(jù)庫(kù)的性能呢?那就是日志文件空間容量.

現(xiàn)在已經(jīng)知道,日志在設(shè)置好后其容量是固定的,它是循環(huán)使用的,如果不夠用了,引發(fā)的事件是做一個(gè)檢查點(diǎn),讓最小有效的LSN向前推,讓出一部分空間給新產(chǎn)生的日志來(lái)使用,也就是說(shuō),只要這個(gè)日志空間未用完,那么Buffer Pool中的Page將會(huì)一直不刷盤(因?yàn)檫€有其它的刷盤時(shí)機(jī),所以這里單指因?yàn)槿罩静粔蛴脤?dǎo)致檢查點(diǎn)的刷盤),任何修改都是在內(nèi)存中發(fā)生的,那么下面做一個(gè)計(jì)算.

假如當(dāng)前日志容量設(shè)置為128M,某一個(gè)DML操作只針對(duì)某一行記錄一直做修改操作.每次操作產(chǎn)生日志量為1KB(包括Buffer中數(shù)據(jù)頁(yè)面的修改及UNDO記錄的產(chǎn)生),這樣算下來(lái),128M的日志量可以容納對(duì)這條記錄的131072(128M/1K)次修改,也就是說(shuō),在這么多次修改之后,這個(gè)頁(yè)面才需要刷盤,才會(huì)產(chǎn)生一次隨機(jī)刷盤操作.而如果把日志文件設(shè)置為1280M,很容易知道,這將容納對(duì)這條記錄的1310720次修改,這么多次修改只產(chǎn)生一次隨機(jī)刷盤操作,而如果還是128M的話,需要10次隨機(jī)刷盤.很明顯,日志容量對(duì)數(shù)據(jù)庫(kù)的性能還是有很大影響的.

但也不是設(shè)置的越大越好,這里有兩點(diǎn)需要注意：

1. 如果設(shè)置的非常大,固然性能可能會(huì)很好,但如果某一天(真的有可能到來(lái)),數(shù)據(jù)庫(kù)異常掛了,此時(shí)可能有很多的日志都沒有刷盤,也就是Log flushed up to與Last checkpoint at兩個(gè)值之間相差太多,恢復(fù)起來(lái),可能需要比較長(zhǎng)的時(shí)間.但這個(gè)一般問題不大,本身掛的機(jī)率不大,同時(shí)REDO日志的恢復(fù)是順序的,都是根據(jù)頁(yè)面號(hào)的大小排序恢復(fù)的,所以比較快.同時(shí)在以后的MySQL版本中,會(huì)有多線程REDO恢復(fù)(聽說(shuō)的),這樣就更快了,所以這一點(diǎn)不需要太多擔(dān)心.

2. 日志容量大小的設(shè)置,最好要與Buffer Pool的總大小匹配,假如日志容量太小,Buffer Pool太大,那么這樣的一個(gè)后果是導(dǎo)致Buffer Pool頻繁做檢查點(diǎn),大的Buffer Pool不能被好好的利用.如果是日志容量很大,而Buffer Pool很小,此時(shí)Buffer Page經(jīng)常會(huì)被淘汰出去,增加了IO頻次,同時(shí)如果數(shù)據(jù)庫(kù)意外掛掉,Buffer Pool小的話恢復(fù)起來(lái)也會(huì)比較慢.一般情況下,Buffer Pool的總大小與日志容量的大小比例最好保持在10~5：1的范圍內(nèi).

日志的格式

前面已經(jīng)講述了太多的日志相關(guān)的內(nèi)容了,這一節(jié)將要講一下,具體到一個(gè)日志記錄時(shí),它是如何組織的,一條日志記錄,究竟存儲(chǔ)了什么?在這里都會(huì)說(shuō)清楚.

前面已經(jīng)講到,InnoDB的日志是具有邏輯意義的物理日志,所以日志記錄的格式就不完全是物理信息,而是有一定的邏輯意義,首先看一個(gè)基本的格式,如下圖所示：

圖中各個(gè)列代表的意義如下：

1. Type：日志類型,是一個(gè)日志記錄的最高位,只占一個(gè)字節(jié)的空間.
2. Space：表空間ID值,如果是系統(tǒng)頁(yè)面(UNDO頁(yè)面,或者是字典表頁(yè)面),則是0,如果是索引頁(yè)面,則是這個(gè)索引所在的表空間ID值.
3. Offset：在上面Space所指定的文件中的頁(yè)面號(hào),以頁(yè)面大小為單位,它是第幾個(gè)頁(yè)面(從0開始計(jì)數(shù)),則這個(gè)Offset就是幾.
4. Data：表示這條日志記錄對(duì)應(yīng)的數(shù)據(jù),這個(gè)數(shù)據(jù)是不確定的,根據(jù)不同的Type值而不同,分別具有自己的格式.

Type類型有很多,下面列舉一些在InnoDB中比較常用的類型,并簡(jiǎn)單做一些解釋,以便可以更好的理解.InnoDB中的REDO,究竟是在做什么?究竟是存儲(chǔ)了什么內(nèi)容?功能是什么?知道每個(gè)類型之后,這些問題也就清楚了.

注：下面講到的數(shù)據(jù)記錄,都是以Compact格式的記錄為對(duì)象的,其它類型這里不考慮.

1. MLOG_(1,2,4,8)BYTE： 這四個(gè)類型,表示要在某一個(gè)位置,寫入一個(gè)(兩個(gè)、四個(gè)、八個(gè))字節(jié)的內(nèi)容,在日志記錄中,Type分別是MLOG_1BYTE(MLOG_2BYTES、MLOG_4BYTES、MLOG_8BYTES),Space就是對(duì)應(yīng)的表空間ID,Offset對(duì)應(yīng)的是頁(yè)面號(hào),在Data中,還需要存儲(chǔ)三個(gè)(四個(gè)、六個(gè)、十個(gè))字節(jié),前兩個(gè)為要寫入的數(shù)據(jù)在頁(yè)面內(nèi)的偏移值,因?yàn)轫?yè)面大小為16K,所以需要用兩個(gè)字節(jié)來(lái)存儲(chǔ),而后面才是真正需要寫入的數(shù)據(jù),占一個(gè)(兩個(gè)、四個(gè)、八個(gè))字節(jié),這就是關(guān)于這個(gè)類型的日志的完整內(nèi)容.
2. MLOG_WRITE_STRING：這種類型的日志,其實(shí)和MLOG_1BYTE是類似的,只是MLOG_1BYTE是要寫一個(gè)固定長(zhǎng)度的數(shù)據(jù),而MLOG_WRITE_STRING是要寫一段變長(zhǎng)的數(shù)據(jù),Data部分的格式,首先用2個(gè)字節(jié)存儲(chǔ)在頁(yè)面中的寫入位置,然后是2個(gè)字節(jié)的寫入數(shù)據(jù)長(zhǎng)度,最后是存儲(chǔ)指定長(zhǎng)度的字符串.
3. MLOG_COMP_REC_MIN_MARK：這個(gè)類型的日志,是在將一條記錄設(shè)置為頁(yè)面中的最小記錄(這個(gè)涉及到頁(yè)面管理的內(nèi)容,在一個(gè)頁(yè)面中只有一個(gè)最小記錄,它指向的是B樹下一層的最左邊的節(jié)點(diǎn))時(shí)產(chǎn)生的,因?yàn)橹皇谴騻€(gè)標(biāo)記,存儲(chǔ)內(nèi)容比較簡(jiǎn)單,除了基本的日志頭外,在Data內(nèi)容中只存儲(chǔ)了這條最小記錄在頁(yè)面內(nèi)的偏移位置.
4. MLOG_UNDO_INSERT：這個(gè)類型的日志,是用來(lái)保證一個(gè)插入操作可以在事務(wù)沒有提交的情況下回滾時(shí)用的,在插入一條記錄時(shí),不止要寫一個(gè)插入操作的日志(類型為MLOG_REC_INSERT,后面會(huì)著重介紹),還要寫一個(gè)針對(duì)這個(gè)操作的回滾記錄.我們已經(jīng)知道,回滾記錄的寫入,其實(shí)也是向ibdata文件中寫入數(shù)據(jù),同樣也是寫在Buffer Pool中的,這個(gè)操作對(duì)應(yīng)的REDO日志,就是當(dāng)前介紹的MLOG_UNDO_INSERT類型的日志,在數(shù)據(jù)庫(kù)恢復(fù)時(shí),只有這個(gè)REDO日志做完了,相應(yīng)的UNDO記錄才有效(存在),如果對(duì)應(yīng)的事務(wù)沒有提交,會(huì)通過這個(gè)回滾記錄將這個(gè)插入操作回滾掉,這也正是為什么REDO必須要在UNDO之前執(zhí)行的原因,這是后話.至于這種類型的日志格式是什么樣子的,與前面所說(shuō)類型的區(qū)別還是在Data上面.前面兩個(gè)字節(jié)存儲(chǔ)的是回滾記錄的長(zhǎng)度,接著就是回滾記錄的完整數(shù)據(jù),不包括回滾記錄前后各兩個(gè)字節(jié)的指針信息,具體到回滾記錄的格式,后面會(huì)講述.
5. MLOG_INIT_FILE_PAGE：這個(gè)類型的日志比較簡(jiǎn)單,只有前面的基本頭信息,沒有Data部分,因?yàn)樵贗nnoDB中,初始化一個(gè)頁(yè)面,所有的信息都是固定的,沒有額外的處理,只要表明初始化哪一個(gè)位置的頁(yè)面就好了,所以沒有Data部分.這里初始化頁(yè)面所做的操作,只涉及到對(duì)頁(yè)面中文件管理方面的信息,比如這個(gè)頁(yè)面的頁(yè)面號(hào),文件號(hào)(表空間ID)等信息,這個(gè)與后面將要介紹的MLOG_COMP_PAGE_CREATE是不同的,這個(gè)屬于頁(yè)面管理的文件信息部分的初始化,而MLOG_COMP_PAGE_CREATE屬于頁(yè)面的索引、數(shù)據(jù)存儲(chǔ)方面的管理信息的初始化.后者是在前者的基礎(chǔ)上做的.
6. MLOG_COMP_PAGE_CREATE：這個(gè)類型的日志,其實(shí)和上面已經(jīng)說(shuō)過的MLOG_INIT_FILE_PAGE是一樣的道理,因?yàn)樵贐uffer中創(chuàng)建一個(gè)新的可以使用的頁(yè)面是固定的,只需要存儲(chǔ)一個(gè)類型及要?jiǎng)?chuàng)建的頁(yè)面的位置即可.創(chuàng)建一個(gè)頁(yè)面所做的操作,包括初始化頁(yè)面頭信息,創(chuàng)建頁(yè)面中最小記錄與最大記錄,初始化頁(yè)面中記錄數(shù)、HEAP大小、HEAP首地址及槽信息,初始化之后,這個(gè)頁(yè)面就可以在B樹中使用了,它是一個(gè)頁(yè)面在沒有插入任何數(shù)據(jù)時(shí)的狀態(tài).
7. MLOG_MULTI_REC_END：這個(gè)類型的日志是非常特殊的,它只起一個(gè)標(biāo)記的作用,其存儲(chǔ)的內(nèi)容只有占一個(gè)字節(jié)的類型值.在前面介紹MTR時(shí)說(shuō)到,一個(gè)MTR所寫的日志,要么全部寫入,要么全部不寫入,如何保證這個(gè)原子性就是通過這個(gè)類型的日志來(lái)實(shí)現(xiàn)的,每次MTR提交時(shí),都會(huì)在后面加上這個(gè)日志記錄,用來(lái)表示這個(gè)MTR已經(jīng)結(jié)束了.只有在恢復(fù)的時(shí)候才會(huì)使用到它,在分析MTR時(shí),只有找到這個(gè)日志,前面的日志才會(huì)去做REDO,做完之后,再向后掃描找到這個(gè)日志,然后再去REDO,如此反復(fù),如果有一次找不到了,則說(shuō)明日志文件是不完整的,已經(jīng)掃描到的REDO日志就不會(huì)去執(zhí)行了,從而保證了已經(jīng)執(zhí)行的MTR每個(gè)都是完整的.
8. MLOG_COMP_REC_CLUST_DELETE_MARK： 這個(gè)類型的日志是表示,需要將聚集索引中的某一個(gè)記錄打上刪除標(biāo)志.因?yàn)?眾所周知,在InnoDB數(shù)據(jù)庫(kù)中聚簇索引的刪除在沒有提交之前,只是打了一個(gè)刪除標(biāo)志而已.這個(gè)類型的日志記錄內(nèi)容,除了基本的內(nèi)容之外,其Data數(shù)據(jù)的組成主要包括,兩個(gè)字節(jié)的索引列的個(gè)數(shù)n,兩個(gè)字節(jié)的唯一索引的個(gè)數(shù)u.接下來(lái)存儲(chǔ)的是所有索引列的長(zhǎng)度信息,每個(gè)列用2個(gè)字節(jié)存儲(chǔ),占用空間2*n個(gè)字節(jié),然后,再存儲(chǔ)索引中兩個(gè)系統(tǒng)列信息,分別是TRXID在索引中的列位置信息、ROLLPTR的值及TRXID的值,最后再存儲(chǔ)當(dāng)前要?jiǎng)h除記錄在所在頁(yè)面中的偏移值,也就是那條記錄的頭指針信息.這個(gè)類型的日志,存儲(chǔ)的內(nèi)容比較復(fù)雜,其Data部分使用下圖來(lái)簡(jiǎn)明表示一下：

1. 這里有一個(gè)奇怪的地方是,在給一個(gè)記錄打刪除標(biāo)志時(shí),為什么不使用這條記錄的主鍵值來(lái)直接定位,而是使用了一些在定位記錄時(shí)被認(rèn)為是沒有用的東西呢?因?yàn)槿绻枰獢?shù)據(jù)恢復(fù)了,只需要找到這行記錄的主鍵信息,就可以重新給這個(gè)記錄打刪除標(biāo)志,那為什么存儲(chǔ)的都是一些索引的定義信息,比如,索引列個(gè)數(shù),唯一鍵列個(gè)數(shù),每個(gè)列的長(zhǎng)度等,關(guān)于這個(gè)問題,是因?yàn)檫@里InnoDB還需要考慮其自身的問題,那就是它的REDO日志是半邏輯半物理的,在恢復(fù)時(shí),不能保證對(duì)應(yīng)的數(shù)據(jù)字典是可用的(因?yàn)閿?shù)據(jù)字典的正確性還是需要REDO來(lái)保證),所以這個(gè)日志就會(huì)記錄一些索引的信息,在恢復(fù)時(shí)使用這些信息來(lái)構(gòu)造一個(gè)LOG_DUMMY表及LOG_DUMMY索引,然后再用這個(gè)表和索引來(lái)輔助這個(gè)REDO日志的執(zhí)行,這樣真正的表及索引可以不正確(暫時(shí)的),因?yàn)榇藭r(shí)是不需要它們的.綜合上面所述的日志Data部分,就可以知道這條記錄的確切信息了,也就可以對(duì)它加刪除標(biāo)志了.
2. MLOG_COMP_REC_UPDATE_IN_PLACE：這個(gè)類型的日志,和上面的MLOG_COMP_REC_CLUST_DELETE_MARK基本是差不多的,只是這個(gè)會(huì)在最后存儲(chǔ)原地更新后的記錄信息,包括所有被更新的列的信息,存儲(chǔ)方式是：前面用1個(gè)字節(jié)或2個(gè)字節(jié)來(lái)存儲(chǔ)長(zhǎng)度,后面跟著的是更新后的數(shù)據(jù),直到記錄所有的列為止.
3. MLOG_COMP_REC_DELETE：在InnoDB中,刪除數(shù)據(jù)是通過打刪除標(biāo)志來(lái)實(shí)現(xiàn)的,但是,在事務(wù)提交后做Purge操作時(shí),這條記錄始終是要被刪除的,所以還存在一個(gè)真正的將數(shù)據(jù)記錄刪除的操作,那這個(gè)類型的日志就是用來(lái)記錄這個(gè)動(dòng)作的.不過這個(gè)日志需要記錄的內(nèi)容也比較少,除了基本的日志頭信息之外,在Data中只需要存儲(chǔ)這條記錄在頁(yè)面內(nèi)的偏移即可.那么在恢復(fù)數(shù)據(jù)時(shí),這種類型的日志的作用就是會(huì)將這個(gè)頁(yè)面中的對(duì)應(yīng)的記錄直接刪除掉,而不再是打刪除標(biāo)記那么簡(jiǎn)單了.
4. MLOG_COMP_PAGE_REORGANIZE：這個(gè)類型的日志,表示的是要重組指定的頁(yè)面,其記錄的內(nèi)容也是很簡(jiǎn)單的,只需要存儲(chǔ)要重組哪一個(gè)頁(yè)面即可,沒有Data部分.在恢復(fù)的時(shí)候,找到這個(gè)頁(yè)面,對(duì)其中的數(shù)據(jù)碎片做整理,將頁(yè)面內(nèi)部的記錄一條條向前移,將原來(lái)記錄之間不能再被使用的空間收回合在一起變成一塊連續(xù)的空間,這樣原來(lái)貌似已經(jīng)滿了的頁(yè)面,又可以插入新的數(shù)據(jù)了,這個(gè)就是表的碎片整理過程.
5. MLOG_COMP_REC_INSERT：這個(gè)類型是在插入一條記錄時(shí)產(chǎn)生的,它的產(chǎn)生過程可能存在一點(diǎn)爭(zhēng)議,這里重點(diǎn)說(shuō)一下.首先當(dāng)然還是基本的日志頭信息,然后存儲(chǔ)的是被插入記錄在頁(yè)面內(nèi)的偏移信息,然后就是關(guān)于索引的信息,這些都與上面MLOG_COMP_REC_CLUST_DELETE_MARK類型日志的內(nèi)容相同,然而,再后面,所存儲(chǔ)的信息就比較復(fù)雜了.首先會(huì)計(jì)算出,當(dāng)前要插入的記錄與前一條記錄第一個(gè)不相同的字節(jié)的位置,然后在日志中記錄的是,從這個(gè)位置開始到當(dāng)前記錄結(jié)束位置之間的數(shù)據(jù),當(dāng)然還有一些其它的信息,比如第一個(gè)不相同的字節(jié)的位置信息等.這里主要想說(shuō)的是它這個(gè)設(shè)計(jì)方式,簡(jiǎn)單一點(diǎn)說(shuō),就是當(dāng)前記錄中存儲(chǔ)的只是記錄的后半部分?jǐn)?shù)據(jù),前半部分?jǐn)?shù)據(jù)依賴的是前一條記錄,這樣存儲(chǔ)會(huì)比存儲(chǔ)整個(gè)記錄省多少空間呢?最主要的是,這需要依賴插入數(shù)據(jù)之間的相關(guān)性,如果非常像,則可能會(huì)省一些,否則效果可能不明顯.

上面講述的是,InnoDB存儲(chǔ)引擎中,REDO日志的一部分類型,并對(duì)不同類型做了解釋.從解釋中可以看到,基本上每一個(gè)類型其實(shí)都是具有邏輯意義的,與DML相關(guān)的類型中,不是存儲(chǔ)了列數(shù)據(jù),就是存儲(chǔ)了記錄在頁(yè)面內(nèi)的偏移等信息.

這樣做的優(yōu)點(diǎn)有：

1. 可以寫REDO解析工具,去做一個(gè)第三方的同步工具,或者了解數(shù)據(jù)庫(kù)做了什么操作,類似Binlog內(nèi)容,但側(cè)重點(diǎn)不同.
2. 日志占用空間比全物理日志少.

最大的缺點(diǎn)就是系統(tǒng)首先要保證日志對(duì)應(yīng)的頁(yè)面的正確性,否則會(huì)造成邏輯日志執(zhí)行不成功,或者造成數(shù)據(jù)的不一致等問題,這個(gè)問題在InnoDB中的解決方式,就是后面介紹的Double Write機(jī)制.

本文就此結(jié)束,接下來(lái)繼續(xù)連載,講述有關(guān)日志的其他內(nèi)容.

文章來(lái)自微信公眾號(hào)：DBAce

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4184.html