資料庫實體删除與邏輯删除

概念

邏輯删除：檔案沒有被真正的删除，隻不過是檔案名的第一個位元組被改成作業系統無法識别的字元，通常這種删除操作是可逆的，就是說用适當的工具或軟體可以把删除的檔案恢複出來。

實體删除：指檔案存儲所用到的磁存儲區域被真正的擦除或清零，這樣删除的檔案是不可以恢複的，實體删除是計算機處理資料時的一個概念。

邏輯删除就是對要被删除的資料打上一個删除标記，在邏輯上是資料是被删除的，但資料本身依然存在！而實體删除則是把資料從媒體上徹底删除掉。

自己了解：

1、比如磁盤中的檔案删除，在删除操作時，隻是在檔案配置設定表FAT中做一個删除标記，但磁盤扇區中的檔案資料依然存在，這就是邏輯删除！而實體删除，則是一些軟體在删除時采用一些特定的算法，對删除檔案所在的扇區反複讀寫，以達到徹底删除的目的。至于寫檔案時，扇區的配置設定則是随機的。邏輯删除的檔案容易恢複，而實體删除則很難恢複！

2、就比如删除東西的時候，邏輯删除的時候，沒有删除資料庫裡的資料，是以邏輯删除可以恢複。當實體删除的話，就是把資料庫裡的資料也删除，是以沒辦法恢複。

3、最主要的差別就是能恢複和不能恢複。

差別

• 實體删除是計算機處理資料時的一個概念。
• 邏輯删除就是給要删除的資料打上一個删除标記，在邏輯上是資料是被删除的，但資料本身依然存在(這行記錄還是存在的)，而實體删除則是把資料從存儲媒體上徹底删除掉。
• 邏輯删除的檔案容易恢複，而實體删除則很難恢複！
• 資料庫中的删除操作一般是邏輯删除，被删除的那行記錄仍然是存在的。

其他

真實世界是沒有删除的。訂單廢棄，使用者禁用，員工離職，文稿廢棄，優惠券廢棄都是狀态的變化。是以 SQL 裡面 DELETE 在業務場景裡都不應該出現。

為了安全，生産環境不能有人或有程式是對資料庫的表有 DELETE 權限的。

反對采用邏輯删除的：

• 邏輯删除的設計還會導緻常用的 unique key 失效（當然使用者可将資料行中原來的碼和​

  ​is_deleted​

  ​​ 一起作為 unique key，但是這樣又會出現，再次删除時，系統中無法出現兩個完全相同的 ID，又都是​

  ​is_deleted=1​

  ​的記錄出現）。
• 被“删除”的這條記錄如果在業務中與大量的表有關聯關系，那麼在删除它時，就會引發很多的級聯的更新，或者判斷引用并提示使用者無法修改正被引用的資源。而要保證這些全部更新無誤，又要求事務一定可靠，若産生了狀态不一緻，那麼這些“髒資料”的維護也是很痛苦的。
• 當表中的記錄數越來越大時，查詢起來會越來越慢。

我能了解具體問題需要具體分析，是要“邏輯删除”還是“實體删除”，主要還是要根據實際的業務場景，比如網際網路企業搜 /收集的個人資訊、電商類平台使用者的訂單、金融類平台的交易記錄，肯定是不能删除的。但是對于一些維護中間狀态的資料，如果可以通過記錄日志實作“留檔”那麼就可以真的删掉它。

不知道有沒有那種開源元件，可以自動實作當我從一個表中實體删除一條記錄時，它可以幫我将它轉移到備份表中，我看了一個 MySQL 的審計插件，但是好像并不做這個用途的。或者有類似“ commit log ”那種東東，删除時隻需要記錄一個 log，有需要的時候可以從日志中恢複回來。

​​别删除資料​​

​​邏輯删除真的不是一個好的設計​​

參考

• ​​1​​
• ​​2​​
• ​​3​​