安全考虑，binlog_row_image建议尽可能使用FULL

背景
binlog_row_image这个参数是MySQL5.6新增的参数，默认值是FULL，在5.7版本默认值也是FULL，但今天我看到有客户的 MySQL5.7版本参数模板采用的是MINIMAL而不是FULL，我对这个修改表示疑惑。

通常来讲，对一个参数默认值做出修改，咱们都应该考虑清楚影响范围，因此我准备作一次测试，并得出结论哪一个参数值才是最佳设置。

术语解释

前提：
binlog格式必须为row格式或者mixed格式，不能够是statement格式。

名称解释:
before image：前镜像，即数据库表中修改前的内容。
after image：后镜像，即数据库表中修改后的内容。

binlog_row_image三种设置及异同
binlog_row_image参数能够设置三个合法值: FULL、MINIMAL、NOBLOB
三个不一样值的做用以下：

FULL: Log all columns in both the before image and the after image.
binlog日志记录全部前镜像和后镜像。

MINIMAL: Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image where a value was specified by the SQL statement, or generated by auto-increment.
binlog日志的前镜像只记录惟一识别列(惟一索引列、主键列)，后镜像只记录修改列。

noblob: Log all columns (same as full), except for BLOB and TEXT columns that are not required to identify rows, or that have not changed.

binlog记录全部的列，就像full格式同样。但对于BLOB或TEXT格式的列，若是他不是惟一识别列(惟一索引列、主键列)，或者没有修改，那就不记录。

For the before image, it is necessary only that the minimum set of columns required to uniquely identify rows is logged. If the table containing the row has a primary key, then only the primary key column or columns are written to the binary log. Otherwise, if the table has a unique key all of whose columns are NOT NULL, then only the columns in the unique key need be logged. (If the table has neither a primary key nor a unique key without any NULL columns, then all columns must be used in the before image, and logged.) In the after image, it is necessary to log only the columns which have actually changed.

官方提到:若是没有惟一识别列(惟一索引列、主键列)，例如只有普通key，那么MINIMAL格式的前镜像也会记录全部全部列，但后镜像依然只记录修改列。

分析

1.这个参数若是设置成MINIMAL格式，能够节省很多磁盘空间，节省必定的io。但因为前镜像不记录修改列，只在后镜像记录修改列，若是数据出现误操做，必然不能经过flashback或binlog2SQL等快速闪回工具恢复数据，由于不能经过BinLog生成反向SQL了。

节省磁盘空间: 高
数据安全性: 低

2.这个参数若是设置成NOBLOB格式，在表中TEXT和BLOB等大字段若是不修改，就不记录先后镜像了，其余小字段的列的修改依然记录先后镜像，通常大字段消耗的磁盘空间是很是大的，能够节省很多磁盘空间。而若是表没有大字段，NOBLOB和FULL格式并无区别，若是数据出现误操做，能够经过flashback或BinLog2SQL等快速闪回工具恢复数据。

节省磁盘空间: 中
数据安全性: 中

3.这个参数若是设置成FULL格式，这是MySQL5.6和MySQL5.7的默认设置，binlog记录全部数据的先后镜像，若是数据出现误操做，能够能经过flashback或binlog2sql等快速闪回工具恢复数据。在数据列比较大的状况下，在大量的update、delete操做时，binlog盘增加会很快，比较容易出现“binlog盘快满”的监控告警。

节省磁盘空间: 低
数据安全性: 高

测试过程以下:

1 测试binlog_row_image=MINIMAL

1.1 测试没有主键没有惟一索引

看是否前镜像全保留

日志以下：

binlog_row_image=MINIMAL，没有主键没有惟一索引，确实前镜像全保留，后镜像只有修改列

1.2 测试有主键

看是否前镜像只有主键列，后镜像只有修改列

日志以下：

确实前镜像只有主键列，后镜像只有修改列。就这个缘由，致使不能闪回数据，安全性考虑不该该使用binlog_row_image=MINIMAL。

2 测试 binlog_row_image=noblob

2.1 测试没有主键没有惟一索引

因为没有主键没有惟一索引，因此前镜像是全保留，由于TEXT/blob是修改列，因此后镜像的TEXT/blob列也被保留了。总体和FULL格式一致。

日志以下：

2.2 测试有主键

有主键，修改列依然是TEXT/blob列，因为有主键了，因此前镜像不会强迫包含全部列，但前镜像的的TEXT列被忽略、不包含,后镜像的TEXT列因为是修改列，因此包含。

日志以下：

实验证实binlog_row_image=noblob这个格式，依然存在缺失前镜像的问题，致使某些场景没法闪回，因此也不推荐设置。

2.3 测试有主键，修改列也不是TEXT列

日志以下：

前镜像和后镜像包含除TEXT/BLOB列以外的全部列

结论大多数客户生产的安全性大于一切，在硬盘白菜价的今天，不提倡设置binlog_row_image=MINIMAL参数，应该继续使用默认值binlog_row_image=FULL格式。