事情是這樣的，寫寫改改搞了好久，總算把新功能搞定了，昨天早上過來很開心啊，過來就更新表結構。我是這樣操作的，點這個：

然后這樣把測試數據庫和線上數據庫同步：

本來好好的，可是該死的，我竟然第一步點了數據同步還沒發現。當我點了確定后悠哉了半天才趕緊終止掉，好吧，可此時數據已經覆蓋了一大半了，留我一臉懵逼愣在這；
當時第一反應是找阿里云系統快照，畢竟我記得是設置了自動策略的，然而當我打開策略，我又懵逼了，0個快照！！！好吧，這個后來才知道今年啥時候給取消自動快照了需要手動備份。為了這個，還和阿里云客服妹子發生了以下對話才死心：

跟阿里妹子對話完已經是39分鐘后了（還是做了加急處理的）于是我又趕緊去找我自己備份的，發現最近備份的也在一周前，好吧這時候運營黑著臉過來講電話被打爆了。
還不死心的我于是又去百度谷歌了半天，發現還有一種方法說不定可以恢復，于是趕緊去服務器找一種叫做binlog的二進制文件，里面是MySQL的操作日志，聽說一般情況是這個binlog是關閉的，抱著試試看的心態，我竟然真的在服務器里面找到了這玩意：

9兆多的操作記錄(⊙﹏⊙)b，于是我把文件同步到本地繼續去百度谷歌一下：
首先，我們可以用這么一條語句去查看操作記錄：

mysqlbinlog binlog文件路徑

也可以基于時間查看：

mysqlbinlog --start-date="時間" --stop-date="時間" binlog文件路徑

反正就是刷刷的我的那些什么update操作記錄，什么delete操作記錄就出來了，跑了半分鐘啊，我的心當時在滴血。
然后，就是恢復了，我們需要用到這樣一條語句（恢復到這個時間之前的數據）：

mysqlbinlog --stop-date="時間" binlog文件路徑 | mysql -u root -p

在這個過程中，我遇到了一個這樣的問題：

查了半天原因是因為有些要恢復的數據的id被占用了。于是我清空了線下所有的數據。終于，恢復成功了，什么！最重要的票務信息只恢復了三條？

可是我查了一下中間缺的絕對不止這么多。反正搞不定就，于是我又查到了另一種方法：
根據操作記錄位置獲取：

mysqlbinlog --start-position=開始位置編號 --stop-position=結束位置編號  binlog文件路徑 | mysql -u root -p

當然恢復結果還是三條。。。。。
另外期間還用到了將二進制操作記錄轉成sql文件命令：

mysqlbinlog --start-date="開始時間" --stop-date="結束時間" binlog文件路徑 > /sql文件路徑.sql

然后無論如何恢復，購票記錄都只有那三條。
然后今天只好手工通過沒有被覆蓋到的支出記錄造了一整天。

總結：
操作正式數據庫一定要做好備份！
操作正式數據庫最好通過SQL腳本更新不要直接用Navicat之類的軟件操作
數據庫最好放到類似阿里云RDS上
一定要定期檢查備份比如阿里云系統快照
實在搞不定提前買好機票跑路吧