今天負責的項目，有個重要的表數據被某個同事寫的業務代碼給delete刪除了，導致系統一直報空指針異常告警。然後，運維那邊MySQL的bin log設置的沒6個小時生成一次，恰巧要等一段時間，客戶着急做業務，幸好從阿里雲上把數據庫某個時間點的數據備份出來查到了被刪除的數據，及時補了回來。
物理刪除：指文件存儲所用到的磁存儲區域被真正的擦除或清零，這樣刪除的文件是不可以恢復的，物理刪除是計算機處理數據時的一個概念。如果在數據庫中直接使用delete、drop刪除了表數據，如果沒有備份的話，數據就很難恢復了。
邏輯刪除（軟刪除）：邏輯刪除就是對要被刪除的數據打上一個刪除標記，通常使用一個is_deleted字段標示行記錄是不是被刪除（或者使用一個status字段代表所謂的“刪除”狀態），在邏輯上是數據是被刪除的，但數據本身是依然存在的。
兩者的優劣：
物理刪除一定程度上刪除了暫時“無用”的數據，降低了表的數據量，對性能肯定是有好處的；但是如果沒有備份的話，數據很難恢復。
邏輯刪除恢復的話只要修改is_deleted等類似的狀態標示字段就可以了，但是表的數據量肯定會比物理刪除增加了，並且查詢時經常要考慮到is_deleted字段，對索引都會有影響。
其實大多數業務場景中，很多“刪除”操作對應的都是一個狀態，比如商品現在下架了，以後可能還會上架；員工此次離職了，以後說不定還會“二進宮”，又回老東家上班等等，並且數據往往是很有價值的。從目前來看，我本人還是不支持直接使用物理刪除，尤其是對業務核心表。其實如果使用物理刪除的話，可以把刪除的數據放到一個歷史表（或者叫日誌表）裏面去，這樣不至於數據完全丟失。像金融證券行業的數據庫設計，有的採用交易表和若干張歷史表的設計，每天使用數據遷移工具在閒時對閒聯機日誌表按日期進行轉移，如果有關聯交易就注意下日切問題同時查聯機表和歷史表，歷史表對更早的數據就通過數據整理規約進數據倉庫。不過這種金融證券場景跟主流的互聯網場景，個人感覺跟主流的互聯網公司的業務場景不是太一致，總之，目前採用邏輯刪除的設計還是多一些的吧。
大家還有什麼好的解決方案，歡迎拍磚～～～