老板说：“数据是公司的资产，用户点了删除，不能真删，万一他后悔了呢？万一我们要查账呢？就在数据库里标记一下‘已删除’就行了。”
程序员一听：“懂了！加个is_deleted字段，默认 0，删除改 1。简单！”
警告：这就是典型的“天堂有路你不走，地狱无门你自来”。
软删除不是在删除数据，它是在养僵尸。
🗑️ 理想中的软删除：给数据贴个条
在产品经理眼中，软删除逻辑是这样的：
| 动作 | 代码行数 (理想状态) | 描述 |
|---|---|---|
| 删除数据 | 1 行 | UPDATE user SET is_deleted = 1 WHERE id = 1 |
| 查询数据 | 1 行 | SELECT * FROM user WHERE is_deleted = 0 |
| 恢复数据 | 1 行 | UPDATE user SET is_deleted = 0 WHERE id = 1 |
总计：3 行 SQL。
简直完美，既保留了数据，又满足了业务。
然而，当你加上这个字段的那一刻起，你数据库里的每一条 SQL 语句，都必须为此买单。
🧟♂️ 第一关：无处不在的“Where 诅咒”
你以为只是删除那一行代码变了吗？不。
是你系统里成千上万条查询 SQL 全部都要改。
- 原来的 SQL：
SELECT * FROM orders WHERE user_id = 100 - 现在的 SQL：
SELECT * FROM orders WHERE user_id = 100 AND is_deleted = 0
恐怖故事：
新来的实习生写了一个统计报表，统计“本月销售额”。但他忘了加AND is_deleted = 0。
结果：报表把那些已经退单、已经取消、已经作废的订单全部算进去了。
财务拿着报表去报税，发现金额比实际入账多了几百万。老板气得要把实习生“硬删除”了。
代价：只要漏写一个
is_deleted = 0，就是严重的业务事故（僵尸数据复活）。
🚫 第二关：唯一索引 (Unique Index) 的死结
这是软删除最著名的逻辑死锁。
场景：
- 用户 A 注册了
test@gmail.com。 - 数据库里有唯一索引
UNIQUE KEY (email)。 - 用户 A 注销了账号。你执行软删除：
UPDATE user SET is_deleted = 1 WHERE email = 'test@gmail.com'。
- 此时，数据库里还有这条记录，只是标记为删除了。
- 过了一个月，用户 A 后悔了，想重新注册一个账号，还是用
test@gmail.com。
**Boom！数据库报错：Duplicate entry 'test@gmail.com' for key 'email'**。
数据库大喊：“这邮箱已经存在了啊！（虽然是软删除的）”
程序员的崩溃解法：
解法 1（自废武功）：删掉唯一索引。
后果：失去了数据库层面的保护，代码里一旦有 Bug，就会产生两条一样的脏数据。
解法 2（复合索引）：建立
UNIQUE KEY (email, is_deleted)。漏洞：你只能“软删除”一次。如果用户注销了（is_deleted=1），又注册（is_deleted=0），再注销……第二次注销时，数据库里会有两条
(test@gmail.com, 1)。Boom！又冲突了。解法 3（甚至要把时间戳拉进来）：
把
is_deleted改成deleted_at（时间戳）。默认是 0（或者 NULL）。删除时填入当前时间戳。
唯一索引变成
UNIQUE KEY (email, deleted_at)。这样每次删除的时间不一样，就能共存了。
代价：为了一个软删除，你把最宝贵的唯一性约束搞得复杂无比，还要处理 MySQL 对
NULL值索引的特殊判定（在 MySQL 中，多个 NULL 不算重复，但 0 算重复，这里又有坑）。
🔗 第三关：级联删除 (Cascading) 的哲学题
软删除还会引发一个哲学问题：“如果父亲死了，儿子要不要埋？”
场景：
你有一个“文件夹”表，和一个“文件”表。
- 用户删除了“文件夹 A”。（文件夹 A 变软删除）
- 那“文件夹 A”里面的“文件 1、2、3”怎么办？
选项 A：也把文件 1、2、3 全部软删除。
问题：如果用户要恢复文件夹 A，文件 1、2、3 要不要恢复？
深层问题：万一“文件 2”是用户在删除文件夹之前就已经手动删除的呢？你一键恢复，把用户本来想删的文件也复活了？
选项 B：不动文件，只删文件夹。
问题：你的查询语句会变得极度复杂：
SELECT * FROM file f JOIN folder d ON f.folder_id = d.id WHERE f.is_deleted = 0 AND d.is_deleted = 0。你得时刻盯着父级、祖父级的状态。
代价：树形结构的软删除，基本上就是逻辑的泥潭。写到最后，你都不知道这条数据到底是显示还是不显示。
🐢 第四关：垃圾堆里的性能危机
软删除的本质是：随着时间推移，你的表里 90% 的数据可能都是垃圾（已删除）。
后果：
- 索引膨胀：哪怕是没用的垃圾数据，也会占用索引空间。
- 查询变慢：数据库引擎在扫描数据时，不得不跳过大量的“僵尸行”。
- 甚至影响分区：如果你想把历史数据归档（Archive），因为这些数据还混在主表里，拆分起来非常麻烦。
💡 结论：软删除是“懒惰”的惩罚
很多资深架构师会告诉你：尽量别用软删除。
如果业务真的需要“后悔药”或“历史审计”，请使用更硬核的方案：
- 历史表（Archive Table）：删除就是真删（
DELETE），但在删除前，把数据搬运到一张users_history表里。
- 优点：主表永远干净、轻快；历史表随便堆垃圾。
- 审计日志（Audit Log）：记录一条日志“User A deleted Order 123”，而不是把 Order 123 留在原地变僵尸。
软删除就像是在家里囤垃圾：
你对自己说：“这些快递纸箱先别扔，万一以后搬家要用呢？”
结果就是你家里的纸箱越堆越多，最后连路都走不动了。
技术架构没有完美的银弹，只有在泥潭中做出的权衡（Trade-off）。
“你们公司的删除逻辑是哪种？”
A. 硬汉派：直接 DELETE，删了就没了。
B. 僵尸派：is_deleted = 1，到处都是坑。
C. 搬运派：删之前搬到 history 表。
D. 佛系派：不删，状态改成‘已停用’，反正硬盘便宜。
