MySQL的binlog的格式及優(yōu)缺點(diǎn)分別是什么呢

本篇文章給大家分享的是有關(guān)MySQL的binlog的格式及優(yōu)缺點(diǎn)分別是什么呢，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

MySQL binlog日志有三種格式，分別為Statement,MiXED和ROW.

1.Statement：每一條會(huì)修改數(shù)據(jù)的sql都會(huì)記錄在binlog中。
優(yōu)點(diǎn):
binlog文件較小
日志是包含用戶執(zhí)行的原始SQL,方便統(tǒng)計(jì)和審計(jì)
出現(xiàn)最早，兼容較好
缺點(diǎn)：
存在安全隱患，可能導(dǎo)致主從不一致
對(duì)一些系統(tǒng)函數(shù)不能準(zhǔn)確復(fù)制或是不能復(fù)制

2.ROW不記錄sql語(yǔ)句上下文相關(guān)信息，僅保存哪條記錄被修改。
優(yōu)點(diǎn):
相比statement更加安全的復(fù)制格式
在某些情況下復(fù)制速度更快（SQL復(fù)雜，表有主鍵）
系統(tǒng)的特殊函數(shù)也可以復(fù)制
更少的鎖
更新和刪除語(yǔ)句檢查是否有主鍵，如果有則直接執(zhí)行，如果沒(méi)有，看是否有二級(jí)索引，如再?zèng)]有，則全表掃描
缺點(diǎn)：
binlog比較大（myql5.6支持binlog_row_image）
單語(yǔ)句更新（刪除）表的行數(shù)過(guò)多，會(huì)形成大量binlog
無(wú)法從binlog看見(jiàn)用戶執(zhí)行SQL（5.6中增加binlog_row_query_log_events記錄用戶的query）

3.Mixed: 是以上兩種level的混合使用，一般的語(yǔ)句修改使用statment格式保存binlog，如一些函數(shù)，statement無(wú)法完成主從復(fù)制的操作，則采用row格式保存binlog,MySQL會(huì)根據(jù)執(zhí)行的每一條具體的sql語(yǔ)句來(lái)區(qū)分對(duì)待記錄的日志形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊(duì)row level模式也被做了優(yōu)化，并不是所有的修改都會(huì)以row level來(lái)記錄，像遇到表結(jié)構(gòu)變更的時(shí)候就會(huì)以statement模式來(lái)記錄。至于update或者delete等修改數(shù)據(jù)的語(yǔ)句，還是會(huì)記錄所有行的變更。
優(yōu)點(diǎn):
混合使用row和statement格式，對(duì)于DDL記錄statument,對(duì)于table里的行操作記錄為row格式。
如果使用innodb表，事務(wù)級(jí)別使用了READ_COMMITTED or READ_UMCOMMITTED日志級(jí)別只能使用row格式。
但是使用ROW格式中DDL語(yǔ)句還是會(huì)記錄成statement格式。
缺點(diǎn):
mixed模式中，那么在以下幾種情況下自動(dòng)將binlog模式由SBR模式改成RBR模式。
當(dāng)DML語(yǔ)句更新一個(gè)NDB表
當(dāng)函數(shù)中包含UUID時(shí)
2個(gè)及以上auto_increment字段的表被更新時(shí)
行任何insert delayed語(yǔ)句時(shí)
用UDF時(shí)
視圖中必須要求使用RBR時(shí)，例如創(chuàng)建視圖使用了UUID()函數(shù)

以上就是MySQL的binlog的格式及優(yōu)缺點(diǎn)分別是什么呢，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。