“MySQL從刪庫到跑路”聽起來很不可思議很難發生，但是無奈的事情事實上很容易發生，可能沒那麼嚴重而已。

第一次：

1. 舊的伺服器版本不好使，並且想修改運維方案，需要給雲伺服器換系統。
2. 於是使用一個開源的SSH客戶端finalshell從伺服器上備份網站到本地，wordpress二次開發的網站，一些微信公眾號網頁小應用，一些使用者圖片等等，總共有兩三百兆的零碎檔案。選擇了整個資料夾進行傳輸，經過了很久時間，傳輸完畢，finallshell沒提示錯誤，點開看了看下載到桌面的資料夾，各個目錄都在，點開後下一級目錄結構也如預期，看了看資料夾大小，確實有幾百M，於是認為備份成功了。
3. 於是就放心的重置了滕騰訊雲伺服器系統，從ubuntu變為centos。
4. 重新部署，上傳備份下來的程式碼，執行。
5. 發現出事了，執行不了，一通404,503,500錯誤，於是去找自己編寫的程式碼，發現沒了，幾百M的檔案，只是一些WordPress的備份+某些專案的依賴+部分圖片+所有的目錄結構，注意是目錄結構，目錄結構都在，可是裡面的檔案沒有了，再看桌面備份的檔案，發現確實沒有那些檔案。
6. 由於程式碼沒有本地的備份，沒有放在任何別的程式碼託管平臺，雲伺服器沒有快照，那幾個月開發出來的程式碼，就這樣沒了，血淋淋的教訓（也不算finallshell的鍋吧，檔案數目過多，公司網路不穩定等因素都可能是導致備份失敗的原因，我依舊是finallshell的忠實使用者）。

教訓：

1. 當時一個人開發，所有沒有使用git做版本控制和程式碼託管，這是個大隱患（自己電腦壞了，丟了怎麼辦？）。
2. 為了能隨時隨地做法開發，我使用開源的可道芒果雲在伺服器上搭建了一個雲桌面，可以瀏覽器登陸上去修改程式碼進行除錯，非常方便（這是我在本地沒有原始碼的原因）。
3. 關於檔案的備份，只是簡單的檢驗了一下備份是否成功，沒有檢驗備份下來的檔案目錄的完整性，以後備份應該在伺服器上壓縮好後再傳輸，在對雲伺服器系統進行大的操作以前，一定要建立快照（玩意有什麼重要東西備份漏了，還有方法溯源）。

第二次：

1. 專案上線一兩個月後，某個MySQL資料庫表有近10W條資料了，裡面有大的文字欄位，這張表dump出sql檔案，體積接近300M，可以說很大了。
2. 有一個查詢通過長度20位的單號查詢，這個單號是char型別的，並且沒有建立唯一索引，一次檢索需要大約10s時間，太慢了，對錶進行切片比較費時間，想建立索引臨時提高檢索速度，先治標以後再治本。
3. 單號是純數字的，於是想改成int(20) ,這樣建立唯一索引檢索起來更快，想著改一下資料型別，應該不會丟失資料，出錯了有日誌，有回滾機制，況且阿里雲的RDS資料庫設定了定期快照備份，出問題了恢復應該不難吧，這麼想著就操作完了。
4. 回頭一看：慘了，改了的這個欄位都變成了2147483647，下意識的意識到，這是觸碰到了int型別的最大值了嗎？
5. 果然是這樣，mysql中有符號int型別最大隻能存放2147483647這麼大的數字，學的不紮實，忽略了這一茬，這個欄位資料丟失不恢復，就相當於使用者的資料就亂了，重大事故呀，怪自己太馬大哈，只能刪庫跑路了嗎？