[TOC]
今天這篇文章恼五，我會(huì)繼續(xù)和你介紹在業(yè)務(wù)高峰期臨時(shí)提升性能的方法。從文章標(biāo)題“MySQL 是怎么保證數(shù)據(jù)不丟的哭懈？”灾馒，你就可以看出來(lái)，今天我和你介紹的方法遣总，跟數(shù)據(jù)的可靠性有關(guān)睬罗。

在專欄前面文章和答疑篇中，我都著重介紹了 WAL 機(jī)制旭斥，得到的結(jié)論是：只要 redo log 和 binlog 保證持久化到磁盤容达，就能確保 MySQL 異常重啟后，數(shù)據(jù)可以恢復(fù)垂券。

評(píng)論區(qū)有同學(xué)又繼續(xù)追問(wèn)花盐，redo log 的寫入流程是怎么樣的，如何保證 redo log 真實(shí)地寫入了磁盤菇爪。那么今天卒暂，我們就再一起看看 MySQL 寫入 binlog 和 redo log 的流程

binlog 的寫入機(jī)制

其實(shí)，binlog 的寫入邏輯比較簡(jiǎn)單：事務(wù)執(zhí)行過(guò)程中娄帖，先把日志寫到 binlog cache也祠，事務(wù)提交的時(shí)候，再把 binlog cache 寫到 binlog 文件中近速。

一個(gè)事務(wù)的 binlog 是不能被拆開(kāi)的诈嘿，因此不論這個(gè)事務(wù)多大堪旧，也要確保一次性寫入。這就涉及到了 binlog cache 的保存問(wèn)題奖亚。

系統(tǒng)給 binlog cache 分配了一片內(nèi)存淳梦，每個(gè)線程一個(gè)，參數(shù) binlog_cache_size 用于控制單個(gè)線程內(nèi) binlog cache 所占內(nèi)存的大小昔字。如果超過(guò)了這個(gè)參數(shù)規(guī)定的大小爆袍，就要暫存到磁盤。

事務(wù)提交的時(shí)候作郭，執(zhí)行器把 binlog cache 里的完整事務(wù)寫入到 binlog 中陨囊，并清空 binlog cache。狀態(tài)如圖 1 所示夹攒。

image.png

可以看到蜘醋，每個(gè)線程有自己 binlog cache，但是共用同一份 binlog 文件咏尝。

1. 圖中的 write压语，指的就是指把日志寫入到文件系統(tǒng)的 page cache，并沒(méi)有把數(shù)據(jù)持久化到磁盤编检，所以速度比較快胎食。
2. 圖中的 fsync，才是將數(shù)據(jù)持久化到磁盤的操作允懂。一般情況下厕怜，我們認(rèn)為 fsync 才占磁盤的 IOPS。

write 和 fsync 的時(shí)機(jī)累驮，是由參數(shù) sync_binlog 控制的：

1. sync_binlog=0 的時(shí)候酣倾，表示每次提交事務(wù)都只 write舵揭，不 fsync谤专；
2. sync_binlog=1 的時(shí)候，表示每次提交事務(wù)都會(huì)執(zhí)行 fsync午绳；
3. sync_binlog=N(N>1) 的時(shí)候置侍，表示每次提交事務(wù)都 write，但累積 N 個(gè)事務(wù)后才 fsync拦焚。

因此蜡坊，在出現(xiàn) IO 瓶頸的場(chǎng)景里，將 sync_binlog 設(shè)置成一個(gè)比較大的值赎败，可以提升性能秕衙。在實(shí)際的業(yè)務(wù)場(chǎng)景中，考慮到丟失日志量的可控性僵刮，一般不建議將這個(gè)參數(shù)設(shè)成 0据忘，比較常見(jiàn)的是將其設(shè)置為 100~1000 中的某個(gè)數(shù)值鹦牛。

但是，將 sync_binlog 設(shè)置為 N勇吊，對(duì)應(yīng)的風(fēng)險(xiǎn)是：如果主機(jī)發(fā)生異常重啟曼追，會(huì)丟失最近 N 個(gè)事務(wù)的 binlog 日志。

redo log 的寫入機(jī)制

接下來(lái)汉规，我們?cè)僬f(shuō)說(shuō) redo log 的寫入機(jī)制礼殊。

我給你介紹了 redo log buffer。事務(wù)在執(zhí)行過(guò)程中针史，生成的 redo log 是要先寫到 redo log buffer 的晶伦。

然后就有同學(xué)問(wèn)了，redo log buffer 里面的內(nèi)容悟民，是不是每次生成后都要直接持久化到磁盤呢坝辫？

答案是，不需要射亏。

如果事務(wù)執(zhí)行期間 MySQL 發(fā)生異常重啟近忙，那這部分日志就丟了。由于事務(wù)并沒(méi)有提交智润，所以這時(shí)日志丟了也不會(huì)有損失及舍。

那么，另外一個(gè)問(wèn)題是窟绷，事務(wù)還沒(méi)提交的時(shí)候锯玛，redo log buffer 中的部分日志有沒(méi)有可能被持久化到磁盤呢？

答案是兼蜈，確實(shí)會(huì)有攘残。

這個(gè)問(wèn)題，要從 redo log 可能存在的三種狀態(tài)說(shuō)起为狸。這三種狀態(tài)歼郭，對(duì)應(yīng)的就是圖 2 中的三個(gè)顏色塊。

image.png

這三種狀態(tài)分別是：

1. 存在 redo log buffer 中辐棒，物理上是在 MySQL 進(jìn)程內(nèi)存中病曾，就是圖中的紅色部分；
2. 寫到磁盤 (write)漾根，但是沒(méi)有持久化（fsync)泰涂，物理上是在文件系統(tǒng)的 page cache 里面，也就是圖中的黃色部分辐怕；
3. 持久化到磁盤逼蒙，對(duì)應(yīng)的是 hard disk，也就是圖中的綠色部分寄疏。

日志寫到 redo log buffer 是很快的是牢，wirte 到 page cache 也差不多顶考，但是持久化到磁盤的速度就慢多了。

為了控制 redo log 的寫入策略妖泄，InnoDB 提供了 innodb_flush_log_at_trx_commit 參數(shù)驹沿，它有三種可能取值：

1. 設(shè)置為 0 的時(shí)候，表示每次事務(wù)提交時(shí)都只是把 redo log 留在 redo log buffer 中 ;
2. 設(shè)置為 1 的時(shí)候蹈胡，表示每次事務(wù)提交時(shí)都將 redo log 直接持久化到磁盤渊季；
3. 設(shè)置為 2 的時(shí)候，表示每次事務(wù)提交時(shí)都只是把 redo log 寫到 page cache罚渐。

InnoDB 有一個(gè)后臺(tái)線程却汉，每隔 1 秒，就會(huì)把 redo log buffer 中的日志荷并，調(diào)用 write 寫到文件系統(tǒng)的 page cache合砂，然后調(diào)用 fsync 持久化到磁盤。

注意源织，事務(wù)執(zhí)行中間過(guò)程的 redo log 也是直接寫在 redo log buffer 中的翩伪，這些 redo log 也會(huì)被后臺(tái)線程一起持久化到磁盤。也就是說(shuō)谈息，一個(gè)沒(méi)有提交的事務(wù)的 redo log缘屹，也是可能已經(jīng)持久化到磁盤的。

實(shí)際上侠仇，除了后臺(tái)線程每秒一次的輪詢操作外轻姿，還有兩種場(chǎng)景會(huì)讓一個(gè)沒(méi)有提交的事務(wù)的 redo log 寫入到磁盤中。

1. 一種是逻炊，redo log buffer 占用的空間即將達(dá)到 innodb_log_buffer_size 一半的時(shí)候互亮，后臺(tái)線程會(huì)主動(dòng)寫盤。注意余素，由于這個(gè)事務(wù)并沒(méi)有提交豹休，所以這個(gè)寫盤動(dòng)作只是 write，而沒(méi)有調(diào)用 fsync溺森，也就是只留在了文件系統(tǒng)的 page cache慕爬。

2. 另一種是窑眯，并行的事務(wù)提交的時(shí)候屏积，順帶將這個(gè)事務(wù)的 redo log buffer 持久化到磁盤。假設(shè)一個(gè)事務(wù) A 執(zhí)行到一半磅甩，已經(jīng)寫了一些 redo log 到 buffer 中炊林，這時(shí)候有另外一個(gè)線程的事務(wù) B 提交，如果 innodb_flush_log_at_trx_commit 設(shè)置的是 1卷要，那么按照這個(gè)參數(shù)的邏輯渣聚，事務(wù) B 要把 redo log buffer 里的日志全部持久化到磁盤独榴。這時(shí)候，就會(huì)帶上事務(wù) A 在 redo log buffer 里的日志一起持久化到磁盤奕枝。

這里需要說(shuō)明的是棺榔，我們介紹兩階段提交的時(shí)候說(shuō)過(guò)，時(shí)序上 redo log 先 prepare隘道， 再寫 binlog症歇，最后再把 redo log commit。

如果把 innodb_flush_log_at_trx_commit 設(shè)置成 1谭梗，那么 redo log 在 prepare 階段就要持久化一次忘晤，因?yàn)橛幸粋€(gè)崩潰恢復(fù)邏輯是要依賴于 prepare 的 redo log，再加上 binlog 來(lái)恢復(fù)的激捏。

每秒一次后臺(tái)輪詢刷盤设塔，再加上崩潰恢復(fù)這個(gè)邏輯，InnoDB 就認(rèn)為 redo log 在 commit 的時(shí)候就不需要 fsync 了远舅，只會(huì) write 到文件系統(tǒng)的 page cache 中就夠了闰蛔。

通常我們說(shuō) MySQL 的“雙 1”配置，指的就是 sync_binlog 和 innodb_flush_log_at_trx_commit 都設(shè)置成 1图柏。也就是說(shuō)钞护，一個(gè)事務(wù)完整提交前，需要等待兩次刷盤爆办，一次是 redo log（prepare 階段）难咕，一次是 binlog。

這時(shí)候距辆，你可能有一個(gè)疑問(wèn)余佃，這意味著我從 MySQL 看到的 TPS 是每秒兩萬(wàn)的話，每秒就會(huì)寫四萬(wàn)次磁盤跨算。但是爆土，我用工具測(cè)試出來(lái)，磁盤能力也就兩萬(wàn)左右诸蚕，怎么能實(shí)現(xiàn)兩萬(wàn)的 TPS步势？

解釋這個(gè)問(wèn)題，就要用到組提交（group commit）機(jī)制了背犯。

這里坏瘩，我需要先和你介紹日志邏輯序列號(hào)（log sequence number，LSN）的概念漠魏。LSN 是單調(diào)遞增的倔矾，用來(lái)對(duì)應(yīng) redo log 的一個(gè)個(gè)寫入點(diǎn)。每次寫入長(zhǎng)度為 length 的 redo log， LSN 的值就會(huì)加上 length哪自。

LSN 也會(huì)寫到 InnoDB 的數(shù)據(jù)頁(yè)中丰包，來(lái)確保數(shù)據(jù)頁(yè)不會(huì)被多次執(zhí)行重復(fù)的 redo log。關(guān)于 LSN 和 redo log壤巷、checkpoint 的關(guān)系邑彪，我會(huì)在后面的文章中詳細(xì)展開(kāi)。

如圖 3 所示胧华，是三個(gè)并發(fā)事務(wù) (trx1, trx2, trx3) 在 prepare 階段锌蓄，都寫完 redo log buffer，持久化到磁盤的過(guò)程撑柔，對(duì)應(yīng)的 LSN 分別是 50瘸爽、120 和 160。

image.png

從圖中可以看到铅忿，

1. trx1 是第一個(gè)到達(dá)的剪决，會(huì)被選為這組的 leader；
2. 等 trx1 要開(kāi)始寫盤的時(shí)候檀训，這個(gè)組里面已經(jīng)有了三個(gè)事務(wù)柑潦，這時(shí)候 LSN 也變成了 160；
3. 峻凫，所有 LSN 小于等于 160 的 redo log渗鬼，都已經(jīng)被持久化到磁盤；
4. 這時(shí)候 trx2 和 trx3 就可以直接返回了荧琼。

所以譬胎，一次組提交里面，組員越多命锄，節(jié)約磁盤 IOPS 的效果越好堰乔。但如果只有單線程壓測(cè)，那就只能老老實(shí)實(shí)地一個(gè)事務(wù)對(duì)應(yīng)一次持久化操作了脐恩。

在并發(fā)更新場(chǎng)景下镐侯，第一個(gè)事務(wù)寫完 redo log buffer 以后，接下來(lái)這個(gè) fsync 越晚調(diào)用驶冒，組員可能越多苟翻，節(jié)約 IOPS 的效果就越好。

為了讓一次 fsync 帶的組員更多骗污，MySQL 有一個(gè)很有趣的優(yōu)化：拖時(shí)間崇猫。在介紹兩階段提交的時(shí)候，我曾經(jīng)給你畫了一個(gè)圖身堡，現(xiàn)在我把它截過(guò)來(lái)邓尤。

image.png

圖中拍鲤，我把“寫 binlog”當(dāng)成一個(gè)動(dòng)作贴谎。但實(shí)際上汞扎，寫 binlog 是分成兩步的：

1. 先把 binlog 從 binlog cache 中寫到磁盤上的 binlog 文件；
2. 調(diào)用 fsync 持久化擅这。

MySQL 為了讓組提交的效果更好澈魄，把 redo log 做 fsync 的時(shí)間拖到了步驟 1 之后。也就是說(shuō)仲翎，上面的圖變成了這樣：

image.png

這么一來(lái)痹扇，binlog 也可以組提交了。在執(zhí)行圖 5 中第 4 步把 binlog fsync 到磁盤時(shí)溯香，如果有多個(gè)事務(wù)的 binlog 已經(jīng)寫完了鲫构，也是一起持久化的，這樣也可以減少 IOPS 的消耗玫坛。

不過(guò)通常情況下第 3 步執(zhí)行得會(huì)很快结笨，所以 binlog 的 write 和 fsync 間的間隔時(shí)間短，導(dǎo)致能集合到一起持久化的 binlog 比較少湿镀，因此 binlog 的組提交的效果通常不如 redo log 的效果那么好炕吸。

如果你想提升 binlog 組提交的效果，可以通過(guò)設(shè)置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 來(lái)實(shí)現(xiàn)勉痴。

1. binlog_group_commit_sync_delay 參數(shù)赫模，表示延遲多少微秒后才調(diào)用 fsync;
2. binlog_group_commit_sync_no_delay_count 參數(shù)，表示累積多少次以后才調(diào)用 fsync蒸矛。

這兩個(gè)條件是或的關(guān)系瀑罗，也就是說(shuō)只要有一個(gè)滿足條件就會(huì)調(diào)用 fsync。

所以雏掠，當(dāng) binlog_group_commit_sync_delay 設(shè)置為 0 的時(shí)候廓脆，binlog_group_commit_sync_no_delay_count 也無(wú)效了。

之前有同學(xué)在評(píng)論區(qū)問(wèn)到磁玉，WAL 機(jī)制是減少磁盤寫停忿，可是每次提交事務(wù)都要寫 redo log 和 binlog，這磁盤讀寫次數(shù)也沒(méi)變少呀蚊伞？

現(xiàn)在你就能理解了席赂，WAL 機(jī)制主要得益于兩個(gè)方面：

1. redo log 和 binlog 都是順序?qū)懀疟P的順序?qū)懕入S機(jī)寫速度要快时迫；
2. 組提交機(jī)制颅停，可以大幅度降低磁盤的 IOPS 消耗。

分析到這里掠拳，我們?cè)賮?lái)回答這個(gè)問(wèn)題：如果你的 MySQL 現(xiàn)在出現(xiàn)了性能瓶頸癞揉，而且瓶頸在 IO 上，可以通過(guò)哪些方法來(lái)提升性能呢？

針對(duì)這個(gè)問(wèn)題喊熟，可以考慮以下三種方法：

1. 設(shè)置 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 參數(shù)柏肪，減少 binlog 的寫盤次數(shù)。這個(gè)方法是基于“額外的故意等待”來(lái)實(shí)現(xiàn)的芥牌，因此可能會(huì)增加語(yǔ)句的響應(yīng)時(shí)間烦味，但沒(méi)有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。
2. 將 sync_binlog 設(shè)置為大于 1 的值（比較常見(jiàn)是 100~1000）壁拉。這樣做的風(fēng)險(xiǎn)是谬俄，主機(jī)掉電時(shí)會(huì)丟 binlog 日志。
3. 將 innodb_flush_log_at_trx_commit 設(shè)置為 2弃理。這樣做的風(fēng)險(xiǎn)是溃论，主機(jī)掉電的時(shí)候會(huì)丟數(shù)據(jù)。

我不建議你把 innodb_flush_log_at_trx_commit 設(shè)置成 0痘昌。因?yàn)榘堰@個(gè)參數(shù)設(shè)置成 0蔬芥，表示 redo log 只保存在內(nèi)存中，這樣的話 MySQL 本身異常重啟也會(huì)丟數(shù)據(jù)控汉，風(fēng)險(xiǎn)太大笔诵。而 redo log 寫到文件系統(tǒng)的 page cache 的速度也是很快的，所以將這個(gè)參數(shù)設(shè)置成 2 跟設(shè)置成 0 其實(shí)性能差不多姑子，但這樣做 MySQL 異常重啟時(shí)就不會(huì)丟數(shù)據(jù)了乎婿，相比之下風(fēng)險(xiǎn)會(huì)更小。

小結(jié)

在專欄的第 2 篇和第 15 篇文章中街佑，我和你分析了谢翎，如果 redo log 和 binlog 是完整的，MySQL 是如何保證 crash-safe 的沐旨。今天這篇文章森逮，我著重和你介紹的是 MySQL 是“怎么保證 redo log 和 binlog 是完整的”。

FAQ

問(wèn)題 1：執(zhí)行一個(gè) update 語(yǔ)句以后磁携，我再去執(zhí)行 hexdump 命令直接查看 ibd 文件內(nèi)容褒侧，為什么沒(méi)有看到數(shù)據(jù)有改變呢？

回答：這可能是因?yàn)?WAL 機(jī)制的原因谊迄。update 語(yǔ)句執(zhí)行完成后闷供，InnoDB 只保證寫完了 redo log、內(nèi)存统诺，可能還沒(méi)來(lái)得及將數(shù)據(jù)寫到磁盤歪脏。

問(wèn)題 2：為什么 binlog cache 是每個(gè)線程自己維護(hù)的，而 redo log buffer 是全局共用的粮呢？

回答：MySQL 這么設(shè)計(jì)的主要原因是婿失，binlog 是不能“被打斷的”钞艇。一個(gè)事務(wù)的 binlog 必須連續(xù)寫，因此要整個(gè)事務(wù)完成后豪硅，再一起寫到文件里哩照。

而 redo log 并沒(méi)有這個(gè)要求，中間有生成的日志可以寫到 redo log buffer 中舟误。redo log buffer 中的內(nèi)容還能“搭便車”葡秒，其他事務(wù)提交的時(shí)候可以被一起寫到磁盤中姻乓。

問(wèn)題 3：事務(wù)執(zhí)行期間嵌溢，還沒(méi)到提交階段，如果發(fā)生 crash 的話蹋岩，redo log 肯定丟了赖草，這會(huì)不會(huì)導(dǎo)致主備不一致呢？

回答：不會(huì)剪个。因?yàn)檫@時(shí)候 binlog 也還在 binlog cache 里幻件，沒(méi)發(fā)給備庫(kù)匆浙。crash 以后 redo log 和 binlog 都沒(méi)有了，從業(yè)務(wù)角度看這個(gè)事務(wù)也沒(méi)有提交，所以數(shù)據(jù)是一致的涧衙。

問(wèn)題 4：如果 binlog 寫完盤以后發(fā)生 crash，這時(shí)候還沒(méi)給客戶端答復(fù)就重啟了碍彭。等客戶端再重連進(jìn)來(lái)癣疟，發(fā)現(xiàn)事務(wù)已經(jīng)提交成功了，這是不是 bug惕虑？

回答：不是坟冲。

你可以設(shè)想一下更極端的情況，整個(gè)事務(wù)都提交成功了溃蔫，redo log commit 完成了健提，備庫(kù)也收到 binlog 并執(zhí)行了。但是主庫(kù)和客戶端網(wǎng)絡(luò)斷開(kāi)了伟叛，導(dǎo)致事務(wù)成功的包返回不回去私痹，這時(shí)候客戶端也會(huì)收到“網(wǎng)絡(luò)斷開(kāi)”的異常。這種也只能算是事務(wù)成功的统刮，不能認(rèn)為是 bug侄榴。

實(shí)際上數(shù)據(jù)庫(kù)的 crash-safe 保證的是：

1. 如果客戶端收到事務(wù)成功的消息，事務(wù)就一定持久化了网沾；
2. 如果客戶端收到事務(wù)失旕稀（比如主鍵沖突、回滾等）的消息辉哥，事務(wù)就一定失敗了桦山；
3. 如果客戶端收到“執(zhí)行異吃苌洌”的消息，應(yīng)用需要重連后通過(guò)查詢當(dāng)前狀態(tài)來(lái)繼續(xù)后續(xù)的邏輯恒水。此時(shí)數(shù)據(jù)庫(kù)只需要保證內(nèi)部（數(shù)據(jù)和日志之間会放，主庫(kù)和備庫(kù)之間）一致就可以了。

上期問(wèn)題時(shí)間
“如果一個(gè)數(shù)據(jù)庫(kù)是被客戶端的壓力打滿導(dǎo)致無(wú)法響應(yīng)的钉凌，重啟數(shù)據(jù)庫(kù)是沒(méi)用的咧最。”

這個(gè)問(wèn)題是因?yàn)橹貑⒅笥瘢瑯I(yè)務(wù)請(qǐng)求還會(huì)再發(fā)矢沿。而且由于是重啟，buffer pool 被清空酸纲，可能會(huì)導(dǎo)致語(yǔ)句執(zhí)行得更慢捣鲸。

老師好，有一個(gè)疑問(wèn)：當(dāng)設(shè)置sync_binlog=0時(shí)闽坡，每次commit都只時(shí)write到page cache栽惶，并不會(huì)fsync。但是做實(shí)驗(yàn)時(shí)binlog文件中還是會(huì)有記錄疾嗅，這是什么原因呢外厂？是不是后臺(tái)線程每秒一次的輪詢也會(huì)將binlog cache持久化到磁盤？還是有其他的參數(shù)控制呢代承？

你看到的“binlog的記錄”汁蝶，也是從page cache讀的哦。
Page cache是操作系統(tǒng)文件系統(tǒng)上的??

事務(wù)A是當(dāng)前事務(wù)次泽，這時(shí)候事務(wù)B提交了穿仪。事務(wù)B的redolog持久化時(shí)候，會(huì)順道把A產(chǎn)生的redolog也持久化意荤，這時(shí)候A的redolog狀態(tài)是prepare狀態(tài)么啊片？

不是。

說(shuō)明一下哈玖像，所謂的 redo log prepare紫谷，是“當(dāng)前事務(wù)提交”的一個(gè)階段，也就是說(shuō)捐寥，在事務(wù)A提交的時(shí)候笤昨，我們才會(huì)走到事務(wù)A的redo log prepare這個(gè)階段。

事務(wù)A在提交前握恳，有一部分redo log被事務(wù)B提前持久化瞒窒，但是事務(wù)A還沒(méi)有進(jìn)入提交階段，是無(wú)所謂“redo log prepare”的乡洼。

這兩個(gè)「提交」的含義是不一樣的崇裁。MySQL 事務(wù)中執(zhí)行 commit 命令是第一種「提交」匕坯，也就是我們常說(shuō)的事務(wù)的提交。

但是當(dāng)你執(zhí)行了 commit 命令之后拔稳，MySQL 是不是要確保這個(gè)事務(wù)結(jié)束葛峻？也就是要寫入 redo log 和 binlog。為了保證 crash-safe 和數(shù)據(jù)一致等問(wèn)題巴比，redo log 和 binlog 的寫入使用了兩階段提交協(xié)議术奖，redo log 會(huì)有 prepare 和 committed 兩種狀態(tài)，redo log 提交后會(huì)從 prepare 狀態(tài)進(jìn)入 committed 狀態(tài)轻绞，這就是第二種「提交」采记。

總結(jié)來(lái)說(shuō)，第一種「提交」就是一條表示事務(wù)結(jié)束命令铲球，而第二種「提交」是 MySQL 底層的一種機(jī)制挺庞。

為什么 binlog cache 是每個(gè)線程自己維護(hù)的晰赞，而 redo log buffer 是全局共用的稼病？
這個(gè)問(wèn)題，感覺(jué)還有一點(diǎn)掖鱼，binlog存儲(chǔ)是以statement或者row格式存儲(chǔ)的然走，而redo log是以page頁(yè)格式存儲(chǔ)的。page格式戏挡，天生就是共有的芍瑞，而row格式，只跟當(dāng)前事務(wù)相關(guān)

老師 我想問(wèn)下文件系統(tǒng)的page cache還是不是內(nèi)存, 是不是文件系統(tǒng)向內(nèi)核申請(qǐng)的一塊的內(nèi)存?


是內(nèi)存 page cache是用作操作系統(tǒng)頁(yè)緩沖的, 但是Mysql會(huì)使用direct io, 繞過(guò)操作系統(tǒng)的page cache, 而使用自己的buffer pool, 但自己的buffer pool也是向操作系統(tǒng)申請(qǐng)的...