• insert 查詢(xún)?yōu)榱吮苊鈹?shù)據(jù)沖突，如果此前插入過(guò)數(shù)據(jù)瓷马，當(dāng)前插入的數(shù)據(jù)如果跟主鍵或唯一鍵的數(shù)據(jù)重復(fù)那肯定會(huì)報(bào)錯(cuò)拴还；
• update 時(shí)也會(huì)查詢(xún)因?yàn)楦碌臅r(shí)候很可能會(huì)更新某一塊數(shù)據(jù)；
• delete 查詢(xún)欧聘，只刪除符合條件的數(shù)據(jù)片林；

因此都會(huì)產(chǎn)生日志，在并發(fā)操作非常多的場(chǎng)景下树瞭，查詢(xún)信息會(huì)非常多拇厢，那么如果都記錄下來(lái)會(huì)導(dǎo)致 IO 非常大爱谁，影響 MySQL
性能晒喷，因此如果不是在調(diào)試環(huán)境下，是不建議開(kāi)啟查詢(xún)?nèi)罩竟δ艿摹?/p>

查詢(xún)?nèi)罩镜拈_(kāi)啟有助于幫助我們分析哪些語(yǔ)句執(zhí)行密集访敌，執(zhí)行密集的 select
語(yǔ)句對(duì)應(yīng)的數(shù)據(jù)是否能夠被緩存凉敲，同時(shí)也可以幫助我們分析問(wèn)題，所以寺旺，我們可以根據(jù)自己的實(shí)際情況來(lái)決定是否開(kāi)啟查詢(xún)?nèi)罩尽?/p>

查詢(xún)?nèi)罩灸Ｊ绞顷P(guān)閉的爷抓，可以通過(guò)以下命令開(kāi)啟查詢(xún)?nèi)罩荆?/p>

set global general log=1 set global log output='table';

general_log=1 為開(kāi)啟查詢(xún)?nèi)罩荆? 為關(guān)閉查詢(xún)?nèi)罩荆@個(gè)設(shè)置命令即時(shí)生效阻塑，不用重啟 MySQL 服務(wù)器蓝撇。

③ 慢日志 ：慢查詢(xún)會(huì)導(dǎo)致 CPU、IOPS陈莽、內(nèi)存消耗過(guò)高渤昌，當(dāng)數(shù)據(jù)庫(kù)遇到性能瓶頸時(shí)，大部分時(shí)間都是由于慢查詢(xún)導(dǎo)致的走搁。開(kāi)啟慢查詢(xún)?nèi)罩径栏蹋梢宰?br> MySQL
記錄下查詢(xún)超過(guò)指定時(shí)間的語(yǔ)句，之后運(yùn)維人員通過(guò)定位分析私植，能夠很好的優(yōu)化數(shù)據(jù)庫(kù)性能忌栅。默認(rèn)情況下，慢查詢(xún)?nèi)罩臼遣婚_(kāi)啟的曲稼，只有手動(dòng)開(kāi)啟了，慢查詢(xún)才會(huì)被記錄到慢查詢(xún)?nèi)罩局小Ｊ褂萌缦旅钣涗洰?dāng)前數(shù)據(jù)庫(kù)的慢查詢(xún)語(yǔ)句：

set global slow query log='ON';

使用 set global slow query log='ON' 開(kāi)啟慢查詢(xún)?nèi)罩就阕ⅲ皇菍?duì)當(dāng)前數(shù)據(jù)庫(kù)有效勇垛，如果 MySQL
數(shù)據(jù)庫(kù)重啟后就會(huì)失效。所以如果要永久生效盏触，就要修改配置文件 my.cnf，設(shè)置 slow query log=1 并重啟 MySQL 服務(wù)器。

④ redo log（重做日志） ：為了最大程度的避免數(shù)據(jù)寫(xiě)入時(shí)晰筛，因?yàn)?IO 瓶頸造成的性能問(wèn)題，MySQL
采用了這樣一種緩存機(jī)制拴袭，先將數(shù)據(jù)寫(xiě)入內(nèi)存中读第，再批量把內(nèi)存中的數(shù)據(jù)統(tǒng)一刷回磁盤(pán)。為了避免將數(shù)據(jù)刷回磁盤(pán)過(guò)程中拥刻，因?yàn)榈綦娀蛳到y(tǒng)故障帶來(lái)的數(shù)據(jù)丟失問(wèn)題怜瞒，InnoDB
采用 redo log 來(lái)解決此問(wèn)題。

⑤ undo log（回滾日志） ：用于存儲(chǔ)日志被修改前的值般哼，從而保證如果修改出現(xiàn)異常吴汪，可以使用 undo log 日志來(lái)實(shí)現(xiàn)回滾操作。 undo
log 和 redo log 記錄物理日志不一樣蒸眠，它是邏輯日志漾橙，可以認(rèn)為當(dāng) delete 一條記錄時(shí)，undo log 中會(huì)記錄一條對(duì)應(yīng)的 insert
記錄楞卡，反之亦然霜运，當(dāng) update 一條記錄時(shí)，它記錄一條對(duì)應(yīng)相反的 update 記錄蒋腮，當(dāng)執(zhí)行 rollback 時(shí)淘捡，就可以從 undo log
中的邏輯記錄讀取到相應(yīng)的內(nèi)容并進(jìn)行回滾。undo log 默認(rèn)存放在共享表空間中池摧，在 ySQL 5.6 中焦除，undo log 的存放位置還可以通過(guò)變量
innodb undo directory 來(lái)自定義存放目錄，默認(rèn)值為“.”表示 datadir 目錄作彤。

⑥ bin log（二進(jìn)制日志） ：是一個(gè)二進(jìn)制文件膘魄，主要記錄所有數(shù)據(jù)庫(kù)表結(jié)構(gòu)變更，比如宦棺，CREATE瓣距、ALTER TABLE
等，以及表數(shù)據(jù)修改代咸，比如蹈丸，INSERT、UPDATE、DELETE 的所有操作逻杖，bin log 中記錄了對(duì) MySQL
數(shù)據(jù)庫(kù)執(zhí)行更改的所有操作奋岁，并且記錄了語(yǔ)句發(fā)生時(shí)間、執(zhí)行時(shí)長(zhǎng)荸百、操作數(shù)據(jù)等其它額外信息闻伶，但是它不記錄 SELECT、SHOW 等那些不修改數(shù)據(jù)的 SQL 語(yǔ)句够话。

binlog 的作用如下：

• 恢復(fù)（recovery）：某些數(shù)據(jù)的恢復(fù)需要二進(jìn)制日志蓝翰。比如，在一個(gè)數(shù)據(jù)庫(kù)全備文件恢復(fù)后女嘲，用戶(hù)可以通過(guò)二進(jìn)制日志進(jìn)行 point-in-time 的恢復(fù)畜份；
• 復(fù)制（replication）：其原理與恢復(fù)類(lèi)似，通過(guò)復(fù)制和執(zhí)行二進(jìn)制日志使一臺(tái)遠(yuǎn)程的MySQL數(shù)據(jù)庫(kù)（一般稱(chēng)為 slave 或者 standby）與一臺(tái) MySQL 數(shù)據(jù)庫(kù)（一般稱(chēng)為 master 或者 primary）進(jìn)行實(shí)時(shí)同步欣尼；
• 審計(jì)（audit）：用戶(hù)可以通過(guò)二進(jìn)制日志中的信息來(lái)進(jìn)行審計(jì)爆雹，判斷是否有對(duì)數(shù)據(jù)庫(kù)進(jìn)行注入攻擊。

除了上面介紹的幾個(gè)作用外愕鼓，binlog 對(duì)于事務(wù)存儲(chǔ)引擎的崩潰恢復(fù)也有非常重要的作用钙态，在開(kāi)啟 binlog 的情況下，為了保證 binlog 與 redo
的一致性菇晃，MySQL 將采用事務(wù)的兩階段提交協(xié)議册倒。當(dāng) MySQL 系統(tǒng)發(fā)生崩潰時(shí)，事務(wù)在存儲(chǔ)引擎內(nèi)部的狀態(tài)可能為 prepared（準(zhǔn)備狀態(tài)）和
commit（提交狀態(tài)）兩種谋旦，對(duì)于 prepared 狀態(tài)的事務(wù)剩失，是進(jìn)行提交操作還是進(jìn)行回滾操作屈尼，這時(shí)需要參考 binlog册着，如果事務(wù)在 binlog
中存在，那么將其提交脾歧；如果不在 binlog 中存在甲捏，那么將其回滾，這樣就保證了數(shù)據(jù)在主庫(kù)和從庫(kù)之間的一致性鞭执。

binlog 默認(rèn)是關(guān)閉狀態(tài)司顿，可以在 MySQL 配置文件（my.cnf）中通過(guò)配置參數(shù) log-bin = [base-name] 開(kāi)啟記錄 binlog
日志，如果不指定 base-name兄纺，則默認(rèn)二進(jìn)制日志文件名為主機(jī)名大溜，并以自增的數(shù)字作為后綴，比如：mysql-
bin.000001估脆，所在目錄為數(shù)據(jù)庫(kù)所在目錄（datadir）钦奋。

通過(guò)以下命令來(lái)查詢(xún) binlog 是否開(kāi)啟：

show variables like 'log_%';

avatar

binlog 格式分為: STATEMENT、ROW 和 MIXED 三種：

• STATEMENT 格式的 binlog 記錄的是數(shù)據(jù)庫(kù)上執(zhí)行的原生 SQL 語(yǔ)句。這種格式的優(yōu)點(diǎn)是簡(jiǎn)單付材，簡(jiǎn)單地記錄和執(zhí)行這些語(yǔ)句朦拖，能夠讓主備保持同步，在主服務(wù)器上執(zhí)行的 SQL 語(yǔ)句厌衔，在從服務(wù)器上執(zhí)行同樣的語(yǔ)句璧帝。另一個(gè)好處是二進(jìn)制日志里的時(shí)間更加緊湊，所以相對(duì)而言富寿，基于語(yǔ)句的復(fù)制模式不會(huì)使用太多帶寬睬隶，同時(shí)也節(jié)約磁盤(pán)空間。并且通過(guò) mysqlbinlog 工具容易讀懂其中的內(nèi)容页徐。缺點(diǎn)就是同一條 SQL 在主庫(kù)和從庫(kù)上執(zhí)行的時(shí)間可能稍微或很大不相同理疙，因此在傳輸?shù)亩M(jìn)制日志中，除了查詢(xún)語(yǔ)句泞坦，還包括了一些元數(shù)據(jù)信息窖贤，如當(dāng)前的時(shí)間戳。即便如此贰锁，還存在著一些無(wú)法被正確復(fù)制的 SQL赃梧。比如，使用 INSERT INTO TB1 VALUE(CUURENT_DATE()) 這一條使用函數(shù)的語(yǔ)句插入的數(shù)據(jù)復(fù)制到當(dāng)前從服務(wù)器上來(lái)就會(huì)發(fā)生變化豌熄，存儲(chǔ)過(guò)程和觸發(fā)器在使用基于語(yǔ)句的復(fù)制模式時(shí)也可能存在問(wèn)題授嘀；另外一個(gè)問(wèn)題就是基于語(yǔ)句的復(fù)制必須是串行化的，比如：InnoDB 的 next-key 鎖等锣险，并不是所有的存儲(chǔ)引擎都支持基于語(yǔ)句的復(fù)制蹄皱；

• ROW 格式是從 MySQL 5.1 開(kāi)始支持基于行的復(fù)制，也就是基于數(shù)據(jù)的復(fù)制芯肤，基于行的更改巷折。這種方式會(huì)將實(shí)際數(shù)據(jù)記錄在二進(jìn)制日志中，它有其自身的一些優(yōu)點(diǎn)和缺點(diǎn)崖咨，最大的好處是可以正確地復(fù)制每一行數(shù)據(jù)锻拘，一些語(yǔ)句可以被更加有效地復(fù)制，另外就是幾乎沒(méi)有基于行的復(fù)制模式無(wú)法處理的場(chǎng)景击蹲，對(duì)于所有的 SQL 構(gòu)造署拟、觸發(fā)器、存儲(chǔ)過(guò)程等都能正確執(zhí)行歌豺；它的缺點(diǎn)就是二進(jìn)制日志可能會(huì)很大推穷，而且不直觀，所以类咧，你不能使用 mysqlbinlog 來(lái)查看二進(jìn)制日志馒铃，也無(wú)法通過(guò)看二進(jìn)制日志判斷當(dāng)前執(zhí)行到那一條 SQL 語(yǔ)句∏聪蹋現(xiàn)在對(duì)于 ROW 格式的二進(jìn)制日志基本是標(biāo)配了，主要是因?yàn)樗膬?yōu)勢(shì)遠(yuǎn)遠(yuǎn)大于缺點(diǎn)骗露，并且由于 ROW 格式記錄行數(shù)據(jù)岭佳，所以可以基于這種模式做一些 DBA 工具，比如數(shù)據(jù)恢復(fù)萧锉，不同數(shù)據(jù)庫(kù)之間數(shù)據(jù)同步等珊随；

• MIXED 也是 MySQL 默認(rèn)使用的二進(jìn)制日志記錄方式，但 MIXED 格式默認(rèn)采用基于語(yǔ)句的復(fù)制柿隙，一旦發(fā)現(xiàn)基于語(yǔ)句的無(wú)法精確的復(fù)制時(shí)叶洞，就會(huì)采用基于行的復(fù)制。比如用到 UUID()禀崖、USER()衩辟、CURRENT USER()、ROW COUNT() 等無(wú)法確定的函數(shù)波附。

redo log 和 binlog 有什么區(qū)別艺晴？

redo log（重做日志）和 binlog（歸檔日志）都是 MySQL 的重要的日志，它們的區(qū)別如下：

• redo log 是物理日志掸屡，記錄的是“在某個(gè)數(shù)據(jù)頁(yè)上做了什么修改”封寞。
• binlog 是邏輯日志，記錄的是這個(gè)語(yǔ)句的原始邏輯仅财，比如“給 ID=2 這一行的 c 字段加 1 ”狈究。
• redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實(shí)現(xiàn)的盏求，所有引擎都可以使用抖锥。
• redo log 是循環(huán)寫(xiě)的，空間固定會(huì)用完碎罚；binlog 是可以追加寫(xiě)入的磅废。“追加寫(xiě)”是指 binlog 文件寫(xiě)到一定大小后會(huì)切換到下一個(gè)魂莫，并不會(huì)覆蓋以前的日志还蹲。

最開(kāi)始 MySQL 里并沒(méi)有 InnoDB 引擎，MySQL 自帶的引擎是 MyISAM耙考，但是 MyISAM 沒(méi)有 crash-safe
的能力，binlog 日志只能用于歸檔潭兽。而 InnoDB 是另一個(gè)公司以插件形式引入 MySQL 的倦始，既然只依靠 binlog 是沒(méi)有 crash-safe
能力的，所以 InnoDB 使用另外一套日志系統(tǒng)山卦，也就是 redo log 來(lái)實(shí)現(xiàn) crash-safe 能力鞋邑。

什么是 crash-safe诵次？

crash-safe 是指發(fā)生宕機(jī)等意外情況下，服務(wù)器重啟后數(shù)據(jù)依然不會(huì)丟失的情況枚碗。

什么是臟頁(yè)和干凈頁(yè)逾一？

MySQL
為了操作的性能優(yōu)化，會(huì)把數(shù)據(jù)更新先放入內(nèi)存中肮雨，之后再統(tǒng)一更新到磁盤(pán)遵堵。當(dāng)內(nèi)存數(shù)據(jù)和磁盤(pán)數(shù)據(jù)內(nèi)容不一致的時(shí)候，我們稱(chēng)這個(gè)內(nèi)存頁(yè)為臟頁(yè)怨规；內(nèi)存數(shù)據(jù)寫(xiě)到磁盤(pán)后陌宿，內(nèi)存的數(shù)據(jù)和磁盤(pán)上的內(nèi)容就一致了，我們稱(chēng)為“干凈頁(yè)”波丰。

什么情況下會(huì)引發(fā) MySQL 刷臟頁(yè)（flush）的操作壳坪？

• 內(nèi)存寫(xiě)滿(mǎn)了，這個(gè)時(shí)候就會(huì)引發(fā) flush 操作掰烟，對(duì)應(yīng)到 InnoDB 就是 redo log 寫(xiě)滿(mǎn)了爽蝴；
• 系統(tǒng)的內(nèi)存不足了，當(dāng)需要新的內(nèi)存頁(yè)的時(shí)候纫骑，就會(huì)淘汰一些內(nèi)存頁(yè)霜瘪，如果淘汰的是臟頁(yè)這個(gè)時(shí)候就會(huì)觸發(fā) flush 操作；
• 系統(tǒng)空閑的時(shí)候惧磺，MySQL 會(huì)同步內(nèi)存中的數(shù)據(jù)到磁盤(pán)也會(huì)觸發(fā) flush 操作颖对；
• MySQL 服務(wù)關(guān)閉的時(shí)候也會(huì)刷臟頁(yè)，觸發(fā) flush 操作磨隘。

MySQL 刷臟頁(yè)的速度很慢可能是什么原因缤底？

在 MySQL 中單獨(dú)刷一個(gè)臟頁(yè)的速度是很快的，如果發(fā)現(xiàn)刷臟頁(yè)的速度很慢番捂，說(shuō)明觸發(fā)了 MySQL 刷臟頁(yè)的“連坐”機(jī)制个唧，MySQL 的“連坐”機(jī)制是指當(dāng)
MySQL 刷臟頁(yè)的時(shí)候如果發(fā)現(xiàn)相鄰的數(shù)據(jù)頁(yè)也是臟頁(yè)也會(huì)一起刷掉，而這個(gè)動(dòng)作可以一直蔓延下去设预，這就是導(dǎo)致 MySQL 刷臟頁(yè)慢的原因了徙歼。

如何控制 MySQL 只刷新當(dāng)前臟頁(yè)？

在 InnoDB 中設(shè)置 innodb flush neighbors 這個(gè)參數(shù)的值為 0鳖枕，來(lái)規(guī)定 MySQL 只刷當(dāng)前臟頁(yè)魄梯，MySQL 8
這個(gè)值默認(rèn)是 0。

MySQL 的 WAL 技術(shù)是解決什么問(wèn)題的宾符？

A.防止誤刪除酿秸，找回?cái)?shù)據(jù)用的 B.容災(zāi)恢復(fù)，為了還原異常數(shù)據(jù)用的 C.事務(wù)處理魏烫，為了數(shù)據(jù)庫(kù)的穩(wěn)定性 D.為了降低 IO 成本 答：D 題目解析：WAL
技術(shù)的全稱(chēng)是 Write Ahead Logging（中文：預(yù)寫(xiě)式日志）辣苏，是先寫(xiě)日志肝箱，再寫(xiě)磁盤(pán)的方式，因?yàn)槊看胃露紝?xiě)磁盤(pán)的話(huà) IO 成本很高稀蟋，所以才有了
WAL 技術(shù)煌张。

為什么有時(shí)候會(huì)感覺(jué) MySQL 偶爾卡一下？

如果偶爾感覺(jué) MySQL 卡一下退客，可能是 MySQL 正在刷臟頁(yè)骏融，正在把內(nèi)存中的更新操作刷到磁盤(pán)中。

redo log 和 binlog 是怎么關(guān)聯(lián)的?

它們有一個(gè)共同的數(shù)據(jù)字段井辜，叫 XID绎谦。崩潰恢復(fù)的時(shí)候，會(huì)按順序掃描 redo log：

• 如果碰到既有 prepare粥脚、又有 commit 的 redo log窃肠，就直接提交；
• 如果碰到只有 parepare刷允、而沒(méi)有 commit 的 redo log冤留，就拿著 XID 去 binlog 找對(duì)應(yīng)的事務(wù)。

MySQL 怎么知道 binlog 是完整的?

• statement 格式的 binlog树灶，完整的標(biāo)識(shí)是最后有 COMMIT 關(guān)鍵字纤怒。
• row 格式的 binlog，完整的標(biāo)識(shí)是最后會(huì)有一個(gè) XID event 關(guān)鍵字天通。

MySQL 中可不可以只要 binlog泊窘，不要 redo log？

不可以像寒，binlog 沒(méi)有崩潰恢復(fù)的能力烘豹。

MySQL 中可不可以只要 redo log，不要 binlog诺祸？

不可以携悯，原因有以下兩個(gè)：

• redo log 是循環(huán)寫(xiě)不能保證所有的歷史數(shù)據(jù)，這些歷史數(shù)據(jù)只能在 binlog 中找到筷笨；
• binlog 是高可用的基礎(chǔ)憔鬼，高可用的實(shí)現(xiàn)原理就是 binlog 復(fù)制。

為什么 binlog cache 是每個(gè)線(xiàn)程自己維護(hù)的胃夏，而 redo log buffer 是全局共用的轴或？

因?yàn)?binlog 是不能“被打斷的”，一個(gè)事務(wù)的 binlog 必須連續(xù)寫(xiě)构订，因此要整個(gè)事務(wù)完成后侮叮，再一起寫(xiě)到文件里。而 redo log
并沒(méi)有這個(gè)要求悼瘾，中間有生成的日志可以寫(xiě)到 redo log buffer 中囊榜，redo log buffer
中的內(nèi)容還能“搭便車(chē)”，其他事務(wù)提交的時(shí)候可以被一起寫(xiě)到磁盤(pán)中亥宿。

事務(wù)執(zhí)行期間卸勺，還未提交，如果發(fā)生 crash烫扼，redo log 丟失曙求，會(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ù)是一致的。

在 MySQL 中用什么機(jī)制來(lái)優(yōu)化隨機(jī)讀/寫(xiě)磁盤(pán)對(duì) IO 的消耗双絮？

redo log 是用來(lái)節(jié)省隨機(jī)寫(xiě)磁盤(pán)的 IO 消耗浴麻，而 change buffer 主要是節(jié)省隨機(jī)讀磁盤(pán)的 IO 消耗。redo log 會(huì)把 MySQL
的更新操作先記錄到內(nèi)存中囤攀，之后再統(tǒng)一更新到磁盤(pán)软免，而 change buffer 也是把關(guān)鍵查詢(xún)數(shù)據(jù)先加載到內(nèi)存中，以便優(yōu)化 MySQL 的查詢(xún)焚挠。

以下說(shuō)法錯(cuò)誤的是膏萧？

A.redo log 是 InnoDB 引擎特有的，它的固定大小的 B.redo log 日志是不全的蝌衔，只有最新的一些日志榛泛，這和它的內(nèi)存大小有關(guān)
C.redo log 可以保證數(shù)據(jù)庫(kù)異常重啟之后，數(shù)據(jù)不丟失 D.binlog 是 MySQL 自帶的日志胚委，它能保證數(shù)據(jù)庫(kù)異常重啟之后挟鸠，數(shù)據(jù)不丟失 答：D
題目解析：binlog 是 MySQL 自帶的日志，但它并不能保證數(shù)據(jù)庫(kù)異常重啟之后數(shù)據(jù)不丟失亩冬。

以下說(shuō)法正確的是艘希？

A.redo log 日志是追加寫(xiě)的，后面的日志并不會(huì)覆蓋前面的日志 B.binlog 日志是追加寫(xiě)的硅急，后面的日志并不會(huì)覆蓋前面的日志 C.redo log
和 binlog 日志都是追加寫(xiě)的覆享，后面的日志并不會(huì)覆蓋前面的日志 D.以上說(shuō)法都正確 答：B 題目解析：binlog
日志是追加寫(xiě)的，后面的日志并不會(huì)覆蓋前面的日志营袜，redo log 日志是固定大小的撒顿，后面的日志會(huì)覆蓋前面的日志。

有沒(méi)有辦法把 MySQL 的數(shù)據(jù)恢復(fù)到過(guò)去某個(gè)指定的時(shí)間節(jié)點(diǎn)荚板？怎么恢復(fù)凤壁？

可以恢復(fù)吩屹，只要你備份了這段時(shí)間的所有
binlog，同時(shí)做了全量數(shù)據(jù)庫(kù)的定期備份拧抖，比如煤搜，一天一備，或者三天一備唧席，這取決于你們的備份策略擦盾，這個(gè)時(shí)候你就可以把之前備份的數(shù)據(jù)庫(kù)先還原到測(cè)試庫(kù)，從備份的時(shí)間點(diǎn)開(kāi)始淌哟，將備份的
binlog 依次取出來(lái)迹卢，重放到你要恢復(fù)數(shù)據(jù)的那個(gè)時(shí)刻，這個(gè)時(shí)候就完成了數(shù)據(jù)到指定節(jié)點(diǎn)的恢復(fù)徒仓。比如腐碱，今天早上 9 點(diǎn)的時(shí)候，你想把數(shù)據(jù)恢復(fù)成今天早上
6:00:00 的狀態(tài)蓬衡，這個(gè)時(shí)候你可以先取出今天凌晨（00:01:59）備份的數(shù)據(jù)庫(kù)文件喻杈，還原到測(cè)試庫(kù)，再?gòu)?binlog 文件中依次取出 00:01:59
之后的操作信息狰晚，重放到 6:00:00 這個(gè)時(shí)刻筒饰，這就完成了數(shù)據(jù)庫(kù)的還原。