一般情況如果在大公司刪庫刪表這種情況基本上不會遇到，畢竟給咱們開發(fā)的賬號不會開這么高的權限桥状。但是在小公司的話就不一定娃弓，沒這么規(guī)范，要是咱們手抖一下岛宦，不小心刪錯了咋辦台丛？
比如你delete錯了,把別的行給刪了。然后如果你的數(shù)據(jù)庫binlog配置是
binlog_format = row 和 binlog_row_image = FULL
比如你的delete語句對應的binlog event 類型是
Delete_rows event
然后將它改成
Write_rows event;
把修改的binlog拿回原庫重放就行了砾肺。
如果是你update的話挽霉，那binlog里面也是記錄了數(shù)據(jù)修改前和修改后的值的，你只要對調(diào)這兩行數(shù)據(jù)的位置就行变汪。
推薦使用Flashback工具侠坎，工具的原理就是我上面說的那樣。
還有這種操作不建議在主庫上執(zhí)行裙盾，一般情況是備份一個庫实胸，或者在哪個從庫上執(zhí)行這些操作，確認沒問題的然后再回復主庫確保主庫的安全番官。
但是有些哥們可能比較猛庐完，他可能是drop或者truncate哪個table了或者是drop database了。這種情況下binlog記得只會是一個drop/truncate語句徘熔，所以用上面的方法是搞不定的门躯。
咋辦呢，找之前的全量備份酷师，沒得話...你懂得
找到之前的全量備份然后配合增量的日志恢復讶凉。流程就是：
找到最近一次的全量備份。比如是2019-3-25 晚上11點
通過這個備份恢復出一個臨時庫
在日志備份里面找到2019-3-25 晚上11點之后的日志
將這些日志除了誤刪除的那個語句全部應用到臨時庫上
第4條這個操作山孔，如果你的數(shù)據(jù)庫實例用了GTID模式懂讯，就先
set gtid_next=(你的刪除語句的GTID);begin;commit;
如果沒用這個模式，那只能是應用到這個刪除語句之前先用-stop-position參數(shù)執(zhí)行到這個語句之前台颠，然后-start-position開始這個語句之后的執(zhí)行褐望。
我們做主從備份，為了防止誤刪數(shù)據(jù)導致的問題，可以搞一個延遲一小時的從庫譬挚，就比如我們是一個星期備份一次的锅铅，那我們?nèi)绻诘谄咛斐隽耸裁村e，需要恢復的話减宣，那得跑多久把涡搿！所以弄一個特殊的備庫漆腌，通過
CHANGE MASTER TO MASTER_DELAY = N
來設置這個備庫和主庫有N秒的延遲贼邓，這樣發(fā)現(xiàn)主庫誤操作了，馬上再這個備庫上執(zhí)行 stop slave闷尿，然后通過上面的方法跳過誤刪除的命令塑径，恢復數(shù)據(jù)！
甚至還有更猛的哥們填具，他可能在服務器上在操作啥统舀，比如像刪除一些文件，但是搞錯了劳景，rm刪了整個數(shù)據(jù)庫實例....
沒事別怕.....咱一般至少數(shù)據(jù)庫會搞個主從的...咱刪了主庫誉简，從庫能頂上，對吧盟广！項目還能跑呢闷串！我們再從備份搞過來恢復一下咱們的主庫。不怕不用跑路筋量！
這都是發(fā)生了之后的補救措施烹吵，咱們最好就是預防一下，比如一般來說沒事就不用這么高權限的賬號桨武，然后寫sql的時候最好準備多個腳本肋拔，比如備份腳本，執(zhí)行腳本玻募，回滾腳本等只损。防范于未然！
如有錯誤歡迎指正七咧！
