通过mysqlbinlog工具可以解析查看，mysqlbinlog mysql-bin.000001就可以查看解出后的格式，Statement方式记录的SQL被还原，但是Row方式记录的内容，还是BASE64的结构。
mysqlbinlog -vv mysql-bin.000001就可以将Row方式记录的内容也解开来，可以看到类似这样的内容：
### UPDATE test.a
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’abc’ /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’cba’ /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
我们可以发现，binlog中并没有记录列名，只记录了顺序，这样会有什么风险呢？
单机的时候问题不大，但是在双Master的结构下，这问题可就大了，假设Master A <--> Master B正在相互复制，我在Master B做一个DDL改变了字段顺序，那么从B DDL完成开始，到A接受执行完这个DDL为止，之间A产生的这张表的数据复制到B都是错误的！因为MySQL只按字段顺序应用binlog。
如何避免这个问题呢？有两个办法，最保险的只加字段不删字段，加字段总是在表末尾，一句话：不改变字段的顺序。另一个办法就是改变字段顺序的DDL只在提供服务的主机上执行，如果双Master都提供服务，这就不行了，只能在末尾添加字段。
这只是地雷之一，还有第二个地雷。mysqlbinlog这个工具的作者真的比较懒，-d参数过滤数据库的时候，只有Statement方式记录的SQL能被过滤，所有按Row方式记录的SQL都没有被过滤！也就是说，假设你的数据库是基于Row方式记录binlog的，你想通过mysqlbinlog -d db1来过滤出db1的SQL，这是不靠谱的，所有Row方式记录的SQL全部被解出来了，你要是到数据库去应用这些解出来的SQL，你就准备悲剧了，各种Duplicate Key！
还有一个不算地雷但是值得说一下的是，即使不需要使用-d参数，你需要全部binlog都解出来，到数据库去应用，也会有一个悲剧点，Row方式记录的SQL都是Base64格式，解出来还是一样，传到数据库去执行的话，MySQL还会把这些BASE64的字串解成SQL，再去应用，所以数据库Load可能会增长的很高。
