背景

在 MySQL 日常维护中，要回滚或者恢复数据，我们经常会用 binlog 来在数据库上重放，执行类似下面的语句：

mysqlbinlog mysql-bin.000001 | mysql -hxxxx -Pxx -u

最近遇到了这样一个问题，在重放 binlog 时，mysqld 报这样的错

ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DELIMITER ;

分析

上面的错是说语法不对，难道是 binlog 写错了，为了方便查看，先把 mysqlbinlog 解析结果保存到一个文件

mysqlbinlog mysql-bin.000001 > abc.sql

然后打开 abc.sql 文件，会看到这样的语句

"CREATE TABLE t_binlog_sbr(a int)^@"

最后面的奇怪的 "^@" 这是啥呢，我们用二进制方式打开文件后，发现这个其实是1个字节，值是 00，被显示成 "^@"了。

为啥后面会多 1 个 0 呢，后来发现是用户在用 MySQL C API 时用错了，具体是这个函数 mysql_real_query，基原型是

int mysql_real_query(MYSQL *mysql, const char *stmt_str, unsigned long length)

详细说明参考这里，length 参数表示 stmt_str 的长度，所以正常的调用应该是这样的：

mysq_real_query(mysql, sql, strlen(sql))

可是用户在使用时多加了个1，变成这样

mysq_real_query(mysql, sql, strlen(sql) + 1)

最终导致记录的 binlog 后面多了个 '\0'。 这个问题只在 statement 格式有，row 格式没有。

解决方法

有同学会问，+1 可以，+2、 +3 呢，这个是不可以的，>=2 的都是不行的，语句发过来后，mysqld 在 parse_sql 阶段直接报错返回了，后面就不会执行了。

1) 修改代码

mysq_real_query(mysql, sql, strlen(sql) + 1) 这种用法是不对的，但是 MySQL 却允许，虽然这么用是不对的，但是为了兼容性，最好还是允许这种使用方式，但是在写binlog的时候做个判断，长度是不是写错了，错了的话纠正过来，在 THD::binlog_query 里面改。

2) 5.6 版本加参数

如果是用 5.6 版本的 mysql client 的话，在重放时出错提示信息不一样，是类似下面这样的，更加友好，这个错误是 mysql client 报的，不是mysqld报的：

ERROR at line 24: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected....

5.6 版本的 mysql client 多了一个参数 --binary-mode，允许语句里有 '\0'，所以如果是用5.6的话，就可以不用修改代码，重放binlog时这样做就可以了：

mysqlbinlog mysql-bin.000001 | mysql --binary-mode -hxxxx -Pxx -u