When you have binlog_format=MIXED
some statements will appear as actual SQL. Other statements may get obfuscated like this:
### INSERT INTO `sanma`.`response`
### SET
### @1=743096223
### @2=0
### @3='IR'
### @4='UnderProcess'
### @5=2015-05-29 20:51:34
### @6=743053329
### @7=NULL
### @8=NULL
### @9='758484829'
### @10=1432912893
### @11=758484829
### @12='UnderProcess'
### @13=0
### @14=NULL
### @15=NULL
### @16=NULL
### @17=NULL
# at 20535714
#150529 20:51:33 server id 71 end_log_pos 20535741 Xid = 84151212
COMMIT/*!*/;
That statement was possible to see because the INSERT ... SET
syntax was used.
Other statements may get obfuscated beyond recognition. This is the risk of using MIXED or ROW.
I have dealt with this recently
Jun 02, 2015
: Why binlog capture only postionsWhy binlog capture only postionsMay 15, 2015
: Show sql statements from mysql binlog (GTID)Show sql statements from mysql binlog (GTID)
The only thing you can do is
# Look for INSERT, UPDATE, DELETE statements
mysqlbinlog ... > statements.sql
grep -i "^[IUD][NPE][SDL][EA][RT][TE]" statements.sql > dml.sql
grep -i "^### [IUD][NPE][SDL][EA][RT][TE]" statements.sql >> dml.sql
There are no guarantees you will catch every change in statement form when mysqld switches to binlog_format ROW intermittently.