【背景】
做了 15 年数据库设计，我见过 90% 的业务表都带一个 is_deleted 或 deleted_at 列。理由通常很简单：「万一要恢复呢」「审计需要」「产品说不能真删」。上线时它确实是 5 分钟的事——加一列、改个 WHERE、写个软删方法，Code Review 没人会拦。
但我在一个运营了 12 年的数据平台上，完整见过这个「5 分钟决策」的代价曲线从"无感"走到"每月多花 2 万存储 + 慢查询治理工单翻倍"的全过程。今天想把它摊开，听听大家的数据。
【常见分歧：三种做法，各有各的痛】
我接触过的团队大致分三派：
派一：永远软删，永不真删。 理由：合规、审计、数据恢复。 代价：所有查询都要 WHERE is_deleted = 0，所有二级索引都要带上这个列（否则回表过滤太贵），表膨胀 30%~80%（取决于业务删除率），EXPLAIN 里永远多一个 filter 条件。千万级以下感觉不到，上亿之后 B+ 树页数直接翻倍，写放大 +50% 起步。我见过一张 3 亿行的订单表，因为 is_deleted 列把两个高频索引从 18GB 撑到 27GB，buffer pool 命中率从 99.2% 掉到 97.1%，P99 多了 8ms。
派二：永远硬删 + 独立审计日志表。 理由：主表保持干净，审计走 append-only 日志。 代价：「删除」和「写审计日志」不在一个事务里（跨库场景更麻烦），恢复能力完全依赖日志完整性。更现实的问题是——很多业务方根本不会去查那张审计日志表，它变成了一个"我们做了合规"的摆设，但存储成本照付。
派三：软删 + TTL 定期归档清理。 理由：两全其美，活跃数据干净、历史数据可追溯。 代价：TTL 清理任务本身是一个分布式调度问题（多副本谁跑、跑到一半挂了怎么续、清理窗口内数据一致性），而「TTL 设多少天」又是一个拍脑袋决策——设 7 天业务说不够，设 90 天存储又扛不住。
【我的倾向与理由】
我倾向派三，但有一个硬前提：在加 is_deleted 列的那一刻，就要把 TTL 策略和归档方案一起设计进去，而不是"先上了再说，量大了再补"。
我在线上推过的具体做法：
- 软删后 30 天内可恢复（覆盖业务需求），30 天后迁移到归档表
- 归档表按 deleted_at 月分区，查询走只读副本，不污染主库索引
- 主库 is_deleted 列只保留 30 天"活跃软删"数据，过期数据定时迁移
- 索引策略：高频等值过滤的索引把 is_deleted 放最前面，低频查询的索引不带（用覆盖索引兜底）
- 迁移任务用分片 + 断点续跑，单次迁移 batch=5000，避开业务高峰
但说实话，这套方案的落地成本不低：归档库、调度任务、迁移逻辑、监控告警，加起来大概 2 人周。对于一张日增 5000 行、删除率 5% 的小表，这个投入是荒谬的——直接硬删 + 备份就够了。
所以核心变量是量级：行数量 × 删除率 × 索引数 × 查询频率。这四个数相乘，决定 is_deleted 到底是"免费"还是"昂贵"。但绝大多数团队在加这一列的时候，这四个数一个都没算过。
【想听大家聊的】
- 你们在什么量级（行数量 / 删除率 / 索引数 / QPS）上开始觉得 is_deleted 列"不免费"了？有没有具体的 EXPLAIN 或 buffer pool 数据？
- 有没有团队真的做过"去掉 is_deleted、改硬删 + 审计日志"的逆向迁移？成本多大、业务阻力在哪、回滚方案怎么设计的？
- 合规场景（金融 / 医疗 / 政务）下，软删的保留期限是业务定的还是合规定的？如果合规要求"永久保留但不可查询"，你们在成本和合规之间怎么找平衡？
- 有没有更优雅的替代方案？比如应用层的"版本表 / 事件溯源"模式、PG 的 logical replication 做归档、或者用 CDC（Debezium / Maxwell）把删除事件流出去存对象存储？
我不是来给标准答案的——这个题的正确答案取决于你的删除率、查询模式、合规要求和团队规模。但我想把"5 分钟便利"和"5 年技术债"之间的分界线，用大家线上真实的数据标出来。
有具体数据的优先，「我感觉好像变慢了」的也欢迎，我们一起算。