公司web服務架設在阿里雲全家桶上，資料庫用的也是RDS
昨晚10點，運營同事在社群發文章，提示建立失敗，檢視介面專案的日誌，是detail欄位的型別為text，可能是不夠，需要加長，我選擇了mediumtext型別。
| 資料型別 | 長度 |
|---|---|
| TINYTEXT | 256 bytes |
| TEXT | 65,535 bytes~64kb |
| MEDIUMTEXT | 16,777,215 bytes~16M |
| BLONGTEXT | 4,294,967,295 bytes~4GB |
然後執行一個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?
本作品採用《CC 協議》，轉載必須註明作者和本文連結