**bug，在處理上傳出現異常時執行了delete from t_resource where resource_id = ? or parent_id = ？因為or條件導致使用者的上傳的所有資料被清空了。
檢視是否有開啟log-bin備份
欣慰的是，已經開啟了二進位制日誌備份。那接下來就簡單多了，找到這個二進位制日誌，找到這個節點，去恢復它。執行這個命令，檢視正在寫入的二進位制日誌是哪個檔案
當然也可以flush重新開始乙個檔案寫入。用這個檔名在linux全域性搜下這個檔案在哪==> find / -name mysql,找到這麼久好辦了。
mysqlbinlog -vv --檢視裡面執行刪除操作的pos位置start-datetime='2019-9-24 11:24:00' --stop-datetime='2019-9-24 11:25:20' mysql-bin.000211| grep "t_resource" | more
然後去檢視從**開始執行了刪除
知道了開始和結束的節點，恢復資料就很快了，因為logbin是二進位制日誌，我們把它弄成我們看得懂的
mysqlbinlog -vv --就生成了乙個bin_1448檔案。我們開啟看下start-position=956859551 --stop-position=956863056 mysql-bin.000211 |grep ^"###" >bin_1448
這個就是執行delete刪除的東西
接下去就是把它反過去變成insert語句就ok了
cat bin_1448 | sed -n '開啟，resource.sql 就是我們很多眼熟的sql語句了。。調整執行就很簡單了/###/p
'| sed '
s/### //g;s/\/\*.*/,/g;s/delete from/insert into/g;s/where/select/g;
'|sed -r '
s/(@6.*),/\1;/g
'| sed '
s/@[1-9]=//g
'| sed '
s/@[1-9][0-9]=//g
'>resource.sql
以上只能對delete的誤操作有效，而且binlog是行模式，如果是truncate的語句造成，那只能祈禱有備份檔案了。
參考
mysql資料恢復 mysqlbinlog
恢復資料的關鍵是資料庫開啟了log bin window下my.ini裡 log bin mysql bin 日誌檔案的字首，可修改，如 mysql bin.000001 然後預設放在資料庫根目錄的data資料夾裡 如果誤刪了資料庫，可以用之前備份的資料庫 如2014 05 12 doc命令列下用m...
MySQL binlog實現增量恢復
mysql實時增量備份，採用binlog日誌的好處 掌控所有更改操作,必要時可用於恢復資料 資料庫主從複製的必要條件 root localhost vim etc my.cnf mysqld log bin mysql bin 啟用二進位制日誌，並指定字首 root dbsvr1 service m...
mysqlbinlog 恢復mysql資料
最近做了乙個很危險的操作，update mysql的時候沒有加where條件，導致資料全更改了 後來通過備份恢復了 大家要引以為戒，千萬慎重。於是，我就研究了一下通過mysqlbinlog恢復資料，以下為實際操作步驟。mysql版本5.7.24 關鍵命令 mysqlbinlog stop posit...