mysql誤刪資料
使用delete語句誤刪資料行
使用drop table或者truncate table誤刪資料表
使用drop database語句誤刪資料庫
使用rm誤刪mysql整個例項
對於誤刪行
使用flashback工具閃回，把資料恢復回來。原理是修改binlog的內容，拿回原庫重放，需要確保binlog_format=row和binlog_row_imsge=full
具體恢復時
如果是insert，將binlog event型別是write_rows event改為delete_rows event。
如果是delete則相反。
如果是update，binlog裡有資料修改前和修改後的值，對調這兩行即可。
多個事物也是按照以上原則倒敘執行。
預防：把sql_safe_updates引數設定為on。這樣一來，如果我們忘記在delete或者update語句中寫where條件，或者where條件里面沒有包含索引字段的話，這條語句的執行就會報錯。
對於誤刪庫/表
需要使用全量備份，加增量日誌的方式。要求線上有定期的全量備份嗎，並且實時備份binlog。
假如有人中午12點誤刪了乙個庫，恢復資料的流程如下：
取最近一次全量備份，假設這個庫是一天一備，上次備份是當天0點；
用備份恢復出乙個臨時庫；
從日誌備份里面，取出凌晨0點之後的日誌
把這些日誌，除了誤刪除資料的語句外，全部應用到臨時庫。
注意：為了加速資料恢復，如果這個臨時庫上有多個資料庫，你可以在使用mysqlbinlog命令時，加上乙個–database引數，用來指定誤刪表所在的庫。這樣，就避免了在恢復資料時還要應用其他庫日誌的情況。
在應用日誌的時候，需要跳過12點誤操作的那個語句的binlog：
加速恢復的方法：備份恢復出臨時例項之後，將這個臨時例項設定成線上備庫的從庫，
乙個系統不可能備份無限的日誌，你還需要根據成本和磁碟空間資源，設定乙個日誌保留
的天數。如果你的dba團隊告訴你，可以保證把某個實例恢復到半個月內的任意時間點，這就表示備份系統保留的日誌時間就至少是半個月。
雖然「發生這種事，大家都不想的」，但是萬一出現了誤刪事件，能夠快速恢復資料，將損失
降到最小，也應該不用跑路了。而如果臨時再手忙腳亂地手動操作，最後又誤操作了，對業務造成了二次傷害，那就說不過去了。
Mysql誤刪資料解決方案及kill語句原理
mysql誤刪資料 對於誤刪行 對於誤刪庫 表 需要使用全量備份，加增量日誌程式設計客棧的方式。要求線上有定期的全量備份嗎，並且實時備份binlog。假如有人中午12點誤刪 乙個庫，恢復資料的流程如下 取最近一次全 備份，假設這個庫是一天一備，上次備份是當天0點 用備份恢復出乙個臨時庫 從日誌備份 ...
mysql 解決方案 Mysql解決方案
mysql解決方案 一 centos7安裝mysql5.7 wget rpm uvh mysql80 community release el7 3.noarch.rpm yum repolist all grep mysql 發現預設mysql8.0是預設安裝的，然而我們要安裝的是mysql5.7...
誤刪Path後完美解決方案
每台計算機安裝程式不同，環境變數path會有不同，若誤刪了環境變數path,可以如下完美解決.win r 輸入regedit開啟登錄檔 開始 執行裡輸入regedit 找到 hkey local machine system controlset002 control session manager...