只有5.6受到影响。

复现步骤

原因分析

function/trigger和procedure不同，不能单独执行，必须依赖statement才能存在，这样就决定了 function/trigger 的事务边界必须由statement来定义，所以的时候，会进行检测body中是否有事务边界定义。比如，如果有commit/rollback，或者会引起隐式提交的DDL语句，那么就会报以下错误：

1422 - Explicit or implicit commit is not allowed in stored function or trigger.

MySQL 5.5为什么会成功？ 因为drop temporary table是一个比较特殊的语句，虽然是DDL语句，但不会隐式提交，所以进行了特殊处理，可以使用。

MySQL 5.6 为什么主库会成功，备库会失败呢？ 在打开gtid_mode的情况下，gtid有一个特殊的限制，不能在事务的过程中进行drop temporary table。如果要使用，必须为drop temporary table独立分配一个GTID。

而这样的event在备库slave线程执行的时候，不满足gtid对于drop temproary table的要求，所以报错。

修复方法 既然gtid_mode=on的时候，drop temproary table必须要分配一个gtid，那么也就意味着它虽然不会隐式提交，但还是定义了事务边界。修复方法就是就在gtid_pre_statement_checks的时候，对于这样的情况就拒绝执行。

5.1、5.5、5.6都受影响。

复现步骤

use test;
set names gbk;
create table test.`t_测试_table`(id int);
drop table test.`t_测试_table`;

原因分析 首先环境设置:

牵涉到的字符集如下:

session环境:     gbk
表名和文件名:     system_charset
query_event:     gdk
drop table test.`t_测试_table`：
session环境:     gbk
query串:     gbk
表名和文件名:     system_charset
query_event:     system_charset

修复方法 对于/* generated by server */的event，不沿用session的字符集，而是使用主库产生event时用的字符集。

5.1、5.5、5.6都受影响。

复现步骤

原因分析 archive是一个归档引擎，在写入的时候，必须按照递增顺序，也就是不能写入一个比当前pk小的记录，引擎层做了硬编码限制:

We don't support decremening auto_increment. They make the performance
just cry.
if (temp_auto <= share->archive_write.auto_increment &&
    mkey->flags & HA_NOSAME)
{
  rc= HA_ERR_FOUND_DUPP_KEY;
  goto error;

而alter的过程中，因为没有指定auto_increment的值，所以auto_increment会从原表中继承过来，也就是等于2，而在copy数据的时候，先插入pk=1的记录，发现比当前auto_increment值小，就报了上面的错误。

修复方法