0、导读
在复制环境中，有个表的列类型总是被修改，导致复制进程报错停止
1、问题描述
问题发生在朋友的数据库上，做了主从复制，其中某表有一列类型是INT，但是该表上的INSERT事件在BINLOG中却总被记录为MEDIUMINT类型，导致这个事件在SLAVE上执行失败。
相关现场信息见下：
MySQL版本：官方5.5.版本。
表DDL定义：
CREATE TABLE `t` (
`userid` int(10) unsigned NOT NULL DEFAULT 0,
这个表上的INSERT事件在BINLOG中的记录：
### INSERT INTO `imysql`.`t`
### SET
### @1=207 /* MEDIUMINT meta=0 nullable=0 is_null=0 */
我们看到BINLOG中，这个列类型显示为MEDIUMINT，这个事件在SLAVE上就会报告下面的错误，导致SLAVE无法继续复制：
Column 0 of table 'imysql.t' cannot be converted from type 'mediumint' to type 'int(10) unsigned
又是一个看起来很奇葩的案例。
2、原因分析
经过沟通排查，了解到他们的业务模式有点特殊，是从一个旧的空表中复制表结构生成每天日志表，然后再将当天的日志写入该表。也就是大概做法是：
1、创建每天日志表
CREATE TABLE t SELECT t_orig;
2、写入日志
INSERT INTO t SELECT * FROM t_orig;
其实问题就出在每天创建新表的过程中，源表结构像是这样的：
CREATE TABLE `t_orig` (
`userid` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
从源表复制到新表之后，又执行了ALTER TABLE，把 userid 列类型从 MEDIUMINT 改为 INT，创建存储过程等其他工作。
生成新表后，再写入生成的日志。但是呢，写入日志却又是采用INSERT...SELECT的用法。一般情况下当然没问题，但这个例子中，源表、目标表的 userid 列类型恰好不一样（源是MEDIUMINT，目标是INT），结果导致在 binglog 中记录event时，将 userid 列类型强制转换为 MEDIUMINT 了。这个 INSERT 在 MASTER 端可以正常执行完毕，但却引发了 SLAVE 检测到二者数据类型不一致，写入失败，复制异常中断。
3、问题建议
遇到这种案例也真的是醉了，从源表每天克隆一个新表做法没问题，采用INSERT...SELECT也没问题，但为啥要源表和新表使用不同数据类型呢，直接把源表的也改成INT不就行了吗，只能说某些人懒得不像样了。
4、类似案例
</div>
AI 代码解读
