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

然后這樣把測試數(shù)據(jù)庫和線上數(shù)據(jù)庫同步：

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

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

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

mysqlbinlog binlog文件路徑

也可以基于時間查看：

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

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

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

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

查了半天原因是因?yàn)橛行┮謴?fù)的數(shù)據(jù)的id被占用了。于是我清空了線下所有的數(shù)據(jù)。終于，恢復(fù)成功了，什么！最重要的票務(wù)信息只恢復(fù)了三條？

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

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

當(dāng)然恢復(fù)結(jié)果還是三條。。。。。
另外期間還用到了將二進(jìn)制操作記錄轉(zhuǎn)成sql文件命令：

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

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

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