软删除（deleted 标志位）到底该不该加？DBA 视角下的三种做法与取舍

背景： 带团队做表设计这 15 年，被业务方和开发问得最多、也最容易当场吵起来的一个问题，就是「这张表要不要加个 deleted 字段做软删除？」。我的体感是：几乎每个团队都有软删除，但很少有人能清楚说出「为什么加、加在哪些表、索引怎么配套」。今天想借这个帖把几种常见做法摊开，聊聊各自的代价。

常见分歧 / 三种做法：

1. 全量软删除派：每张业务表都加 deleted（0/1 或 0/1/2 多态），物理删除只出现在归档脚本里。优点是「数据永远可恢复、审计友好、误操作有兜底」；代价是每个查询都要带 where deleted=0，联合索引第一个字段被迫塞进 deleted，索引选择性被稀释，表还只增不减，越滚越大。
2. 关键表软删、流水表物理删派：订单主表、账户、合同这类强关联、强审计的加 deleted；日志、流水、埋点这类只追加、可重放的直接物理删或走归档。优点是「按数据价值分级」，索引干净；代价是规则得团队自己约定，新人容易踩错，跨表 JOIN 时一边软删一边物理删，语义容易不一致。
3. 无软删除、靠事务/备份/归档兜底派：相信「删错了就回滚 / 从 binlog 或冷备恢复」，表里不留 deleted。优点是模型最干净、查询最快；代价是误删恢复成本高、审计追溯要跨系统，且和「先删后补」的业务流程天然冲突。

我的倾向与理由： 我倾向「分级 + 强制约定」，也就是第 2 种，但会再补三条硬规则：

1. 软删除字段必须是「可索引前缀」：如果 deleted 要进联合索引，就让它放最前，并且把「有效行」的取值设计成少数派（比如正常=0 占绝大多数），让索引局部性还在；
2. 软删除要配「删除时间 + 删除人」两个字段，否则审计价值减半，等于白加；
3. 凡是「逻辑删 + 唯一约束」的表（比如手机号、邮箱唯一），软删除后必须把唯一键改成 (业务键, deleted_id) 这种可空唯一，否则「删了又建」会撞唯一索引——这是我见过最高频的坑。 我不建议无脑全量软删：流水表加 deleted 纯属自找麻烦，它本来就该追加 + 归档。

想听大家在什么场景下怎么选：

• 你的「强一致业务表」和「流水/日志表」在删除策略上是怎么分的？
• 软删除后唯一约束你们怎么处理的？有没有踩过「删了建不了」的坑？
• 有没有人试过「不建 deleted、纯靠 binlog/备份恢复」？误删恢复实际花了多久、代价多大？
• 多态删除（0/1/2 区分「用户删 / 系统删 / 冻结」）你们觉得值不值？

欢迎贴你们团队的约定和翻车案例，越具体越好。