原创声明:本文为作者原创，未经允许不得转载，经授权转载需注明作者和出处
事情是这样的，写写改改搞了好久，总算把新功能搞定了，昨天早上过来很开心啊，过来就更新表结构。我是这样操作的，点这个：
然后这样把测试数据库和线上数据库同步：
本来好好的，可是该死的，我竟然第一步点了数据同步还没发现。当我点了确定后悠哉了半天才赶紧终止掉，好吧，可此时数据已经覆盖了一大半了，留我一脸懵逼愣在这；
当时第一反应是找阿里云系统快照，毕竟我记得是设置了自动策略的，然而当我打开策略，我又懵逼了，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上
一定要定期检查备份比如阿里云系统快照
实在搞不定提前买好机票跑路吧
