MySQL · 捉虫动态 · BUG 几例
最后更新于：2022-04-01 10:38:28
随着RDS MySQL用户越来越多，隐藏很久很深的bug也逐渐被挖出来了，下面分享一下最近遇到的三例bug，都是官方版本存在的。
## trigger/function中drop temporary table导致slave中断
只有5.6受到影响。
复现步骤
~~~
打开gtid_mode=ON
create function `test_func_1` () returns varchar(30) charset utf8
begin
drop temporary table if exists test_func_1;
drop temporary table if exists test_func_2;
return "hello";
end;
select test_func_1();
~~~
原因分析
function/trigger和procedure不同，不能单独执行，必须依赖statement才能存在，这样就决定了 function/trigger 的事务边界必须由statement来定义，所以`create function/trigger`的时候，会进行检测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。
复现方法中的function在主库执行的时候，产生的binlog event如下：
~~~
| master-bin.000001 | 580 | Gtid | 1 | 628 | SET @@SESSION.GTID_NEXT= 'cfef3544-1327-11e5-8a6f-2c44fd7a5210:2' |
| master-bin.000001 | 628 | Query | 1 | 779 | DROP TEMPORARY TABLE IF EXISTS `test`.`test_func_1` /* generated by server */ |
| master-bin.000001 | 779 | Query | 1 | 930 | DROP TEMPORARY TABLE IF EXISTS `test`.`test_func_2` /* generated by server */ |
~~~
而这样的event在备库slave线程执行的时候，不满足gtid对于`drop temproary table`的要求，所以报错。
修复方法
既然gtid_mode=on的时候，`drop temproary table`必须要分配一个gtid，那么也就意味着它虽然不会隐式提交，但还是定义了事务边界。修复方法就是就在`gtid_pre_statement_checks`的时候，对于这样的情况就拒绝执行。
## drop带有中文表名的语句在备库执行失败
5.1、5.5、5.6都受影响。
复现步骤
~~~
use test;
set names gbk;
create table test.`t_测试_table`(id int);
drop table test.`t_测试_table`;
~~~
原因分析
首先环境设置:
~~~
set names gbk;
create table test.`t_测试_table`(id int);
~~~
牵涉到的字符集如下:
~~~
session环境: gbk
query串: gbk
表名和文件名: system_charset
query_event: gdk
drop table test.`t_测试_table`：
session环境: gbk
query串: gbk
表名和文件名: system_charset
query_event: system_charset
~~~
因为`drop table`的query event是/* generated by server */，在主库生成的时候使用的字符集为system_charset，而在备库执行的时候，需要初始化session环境为主库带过来是gbk，而event本身是system_charset的，导致event和session环境的charset不一致，无法找到表而slave中断。
修复方法
对于/* generated by server */的event，不沿用session的字符集，而是使用主库产生event时用的字符集。
## 带有auto_increment字段的表转成archive引擎报错
5.1、5.5、5.6都受影响。
复现步骤
~~~
create table test.t(id int primary key auto_increment, col1 int) engine=innodb;
insert into test.t values(1, 2);
insert into test.t values(2, 2);
commit;
alter table test.t engine= archive;
ERROR 1022 (23000): Can't write; duplicate key in table '#sql-db11_2bfaa
~~~
原因分析
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`值小，就报了上面的错误。
修复方法
语句`alter table t engine=archive`，在转换成archive引擎的时候，如果没有指定`auto_increment`的值的时候，系统默认指定成0， 而不是沿用原表的当前`auto_increment`值。