引言
資料庫一直是個大問題。如果沒有做資料備份,或者是開啟binlog,那真得就是沒了就是沒了,全表更新就是真的回不去了,就算開啟了備份,也很麻煩。光是資料恢復就夠喝一壺的,而且說不影響線上正在跑的業務,那是騙人的。那麼如果做到防止資料庫誤刪或者是誤更新,可以參考下以下幾點,下面總結的都是業務層面,和一些配置層面。
防護手段
業務程式碼
-
update delete 儘量不允許where條件為空
- ThinkPHP框架where為空導致全表
$whereString = ""; $whereArr = []; $sql1 = M(`test`)->where($whereString)->buildSql(); $sql2 = M(`test`)->where($whereArr)->buildSql(); echo $sql1; // SELECT * FROM mall_test echo $sql2; // SELECT * FROM mall_test
- 分析:
那麼問題就很尷尬了。程式設計師沒好好檢查下where條件,有可能傳了空的字串或者陣列,TP框架原始碼我看了下,也僅僅只做了是否有傳參的檢查,這還遠遠不夠 - 解決思路:
業務程式碼中每次where必須檢查,大原則上不允許where為空。資料查詢也不行,不小心掃描全表也造成IO和內網頻寬的開銷
- 軟刪除代替物理刪除
這個就是比較常見的手段了,一般是多加一個欄位is_delete
等等標記狀態的欄位,如有必要,再加上刪除時間。軟刪除的好處也很明顯,如果是業務發現誤刪,還能有迴旋的餘地。又或者,在一些線上業務中,比如說可以多一個功能,比如說使用者是VIP,可以恢復以前刪除的文章或者是圖片等等,看似很厲害,很貼心,其實就是改變刪除狀態而已。
資料庫配置
- 啟動引數限制更新必須有條件(這裡以mysql為例)
-U, –safe-updates Only allow UPDATE and DELETE that uses keys.
其實UPDATE更新表也要注意防止全表更新,因為更新也產生了不可逆的結果。 -
grant配置許可權
分配的使用者應該滿足最小可用許可權
。比如WEB應用的運算元據庫賬號。root賬號在非必須情況下,儘量不要參與日常運維,維護的工作。勤於多多分配賬號。許可權的話也要控制好,比如你開放DROP TURNCATE
等等這些危險命令幹嘛。如果是用了軟刪除的邏輯,那麼DELETE應該也不允許開放