公司 web 服务架设在阿里云全家桶上，数据库用的也是 RDS

昨晚 10 点，运营同事在社区发文章，提示创建失败，查看接口项目的日志，是 detail 字段的类型为 text，可能是不够，需要加长，我选择了 mediumtext 类型。

然后执行一个 DDL 语句，如下：

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumint  DEFAULT NULL COMMENT '内容';

执行完了，好的，告诉运营同事，看下可以发文章了么？

还是不行，哦，DDL 写错了，应该是【mediumtext】，这里错了，把正确的 DDL 语句执行一遍，再问下运营同事

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '内容';

基于一个好的习惯，我再去社区确认下，运营同事的新帖子内容挺不错，在随便点点别的帖子。

嗯？我凑？？？社区全部帖子的内容变成 0 了，如下

懵逼了，生产事故吖，看看咋回事，一个想法闪过，sql 有问题，我用 navicat 生成的 sql 语句，更新后的数据类型应该是【mediumtext】，结果我敲到 med 的时候，他就主动补全了【mediumint】，没有看清，就放到生产执行了，一下子把所有 detail 的内容，强制转换成了数字？？

黑人问号脸.jpg

ok，开始想办法恢复数据，中间各种想办法，最后依靠阿里云提供的数据备份管理功能，和本人一瞬间暴涨的工作效率和好运气，在今天凌晨 1 点搞定了。

至此，我得到了这个表本来的数据了，好在备份时间和发成事故的时间很相近，又是过年期间发帖频率很低，查一下表内行数，好的，备份库的贴子表只差一个生产库一行，应该就是运营那一篇了，哈哈哈。

执行一个兜底命令，重命名帖子表，先不要删掉这个表，避免一错再错

RENAME TABLE  aws_question to aws_question_bak;

然后把导出来的.sql 文件上传到可以连接生产库的服务器，然后把这个.sql 执行下，导入到生产库里

$ mysql -h hostname -u username -p < restore.sql 
Enter password:   #输入root用户的密码。

再回来看看贴子，好的，数据恢复了。

回过头来，我们在执行一遍更新字段数据类型的 sql

ALTER TABLE `databasename`.`tablename` CHANGE COLUMN `question_detail` `question_detail` mediumtext  DEFAULT NULL COMMENT '内容';

把运营同事新写的文章，从 bak 表拿出来，导入到本表中，至此，数据完全存进去了。

?Happyending?