上回講到通過當天的binlog用各種方法都只能找回三條，原因是太心急了百度的東西只知其一不知其二，后來靜下心來仔細研究了一番binlog，總算搞清楚咋回事了。

首先，我理解錯了binlog的意思，并不是拿著最后的binlog就可以按時間恢復所有的東西，binlog是MySQL的操作記錄，它里面儲存了MySQL下所有的crud，因此，要恢復哪些天丟失的數據就要把這些天的東西全部找出來像這樣，按照binlog的創建時間從服務器上拿

然后，我們把它放到一起，還是用mysqlbinlog命令，多個文件可以用空格隔開

mysqlbinlog binlog1文件路徑 binlog2文件路徑 ...

然后就可以在控制臺看到這些天所有的操作記錄了。
然后，就可以通過恢復命令從多個binlog文件內恢復數據了

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

額，當然，這個過程并不順利，運行之后就報了個錯，沒有圖了，反正查了半天發現是因為表結構更改造成的（這個坑把自己埋得慘啊）

既然自動恢復的路被堵死了，那就只能手動恢復了，記得之前講到這樣一條轉成SQL語句的命令：

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

改成這樣

mysqlbinlog binlog1文件路徑 binlog2文件路徑... > /要生成的sql文件路徑.sql

這樣就可以將這么多天的文件全部都生成在了一個文件里；
文件打開我又要瘋了

總共有一百一十多萬行這么多，我要在里面尋找、搜索我需要的crud，然后找到了之后放到另一個文件，找完了把表結構更改的在手動修改一下，最后運行這些語句，然后核對數據（此過程總共用了三天三夜），
然后就好了。
總結：

• 無論需求多蛋疼都盡可能不要修改現有的表結構；
• binlog是個好東西，關鍵的時候可以救命；
• 看文檔不能看到一半，對于未知領域，最好從helloword開始來，心急什么豆腐都吃不到；