一：背景
线上需要做个管理功能，设计时，设计了一张主表，一张记录重点事项记录表，重点事项是可以查看以前的修改记录。所以一次编辑修改，会直接update所有信息到主表中，判断重点事项是否发生修改。再插入到副表中。但是修改了重点事项表，发现主表时间并未更新。猜测并没有真正更新到数据库中。
二：环境
查看mysql版本：
1 ./mysql -p select version() from dual;
MySQL5.7.12
查看linux系统版本：
1 lsb_release -a
Centos 7.4
三：binlog_format为ROW
1、参数
show variables like 'binlog_row_image'; show variables like 'binlog_format'; show variables like 'tx_isolation';
2、验证阶段
创建last_update_time字段，设置该字段根据当前时间更新。
发现修改字段跟原数据相同时，当前时间并不会更新。
而修改数据不同时，当前时间才会更新。说明，数据相同时，不会执行。
3、总结
在 binlog_format=row 和 binlog_row_image=FULL 时，
由于MySQL 需要在 binlog 里面记录所有的字段，所以在读数据的时候就会把所有数据都读出来，那么重复数据的update不会执行。即MySQL 调用了 InnoDB 引擎提供的“修改”这个接口，但是引擎发现值与原来相同，不更新，直接返回。
mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。
① STATEMENT模式（SBR）
每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)
② ROW模式（RBR）
不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。
③ MIXED模式（MBR）
以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。
如有错误的地方，请指出。谢谢评论。
参考文献：