记一次 MySQL 数据库单表恢复事故处理

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《记一次 MySQL 数据库单表恢复事故处理》，文章讲解的知识点主要包括MySQL、数据恢复，如果你对数据库方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

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

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

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

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

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

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

?Happyending?

今天带大家了解了MySQL、数据恢复的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~