软删除设计虽便于数据恢复和合规,但会带来查询复杂度增加、数据库积累大量无用数据等问题。常见如误删恢复仅占1%,多数归档数据永不访问。若未设定期清理机制,长期运行可能导致数百万条冗余数据,尽管存储成本不高,仍需提前规划保留策略。

软删除的挑战与实践思考

作者：atlas9 发布日期：2026年1月19日

核心观点： 软删除虽然常见，但存在诸多潜在问题。文章探讨了传统软删除方案的弊端，并提出了三种替代方案。

一、传统软删除方案的弊端 1. 数据膨胀问题 - 使用deleted布尔值或archived_at时间戳会导致数据库积累大量无用数据 - 典型案例：Terraform误操作导致数百万条无效记录

2. 查询复杂性增加

• 需要额外过滤条件排除已删除数据
• 索引效率降低
• 手动查询和调试更困难

3. 数据迁移挑战

• 迁移脚本需要处理历史数据
• 旧数据可能无法通过新验证规则

4. 恢复复杂性

• 简单设置archived_at=null可能不足
• 需要重新执行完整的创建流程

二、替代方案探讨（PostgreSQL环境）

1. 应用层归档方案 优点：

• 主数据库保持简洁
• 异步处理提高性能
• JSON格式更易使用

缺点： - 实现复杂度高 - 需要额外基础设施 - 查询不便

2. 触发器方案 实现方式：

• 创建通用归档表存储JSON格式数据
• 通过触发器自动备份删除记录

外键级联处理： - 使用会话变量追踪删除根源

优势： - 主表保持干净 - 归档清理简单 - 查询效率高

3. WAL变更数据捕获 实现路径： PostgreSQL → Debezium → Kafka → 消费者 → 归档存储

轻量级替代方案： - pgstream - wal2json - pg_recvlogical

注意事项： - 需要监控复制槽延迟 - 配置maxwalsize防止磁盘溢出

4. 特殊副本方案（理论设想）

• 创建不处理DELETE命令的副本
• 潜在问题：模式迁移难度和存储成本

三、实践建议 作者推荐优先考虑触发器方案： - 实施简单 - 主库保持整洁 - 无需额外基础设施 - 归档数据易于查询和管理

总结： 软删除虽是小功能，但设计不当会带来长期维护负担。选择方案时应权衡实现复杂度、查询效率与运维成本。

以下是评论内容的总结，平衡呈现不同观点：

支持软删除的观点

1. 性能与查询优化

   • 将已删除数据移至单独集合可避免扫描不必要记录（cj）
     "moving the objects to a separate collection... avoids scanning soft deleted records"
   • 视图（view）可自动过滤软删除字段，简化应用逻辑（whalesalad）
     "The view will hide rows that have been soft deleted... application doesn't need to worry"

2. 数据完整性与恢复

   • 软删除保留关系链，便于恢复（MaxGabriel）
     "Undoing is really easy because all relationships stay in place"
   • 45天后硬删除的混合方案兼顾恢复与合规（clickety_clack）
     "Soft delete with hard delete after 45 days... recovers accidental deletions"

3. 历史分析与审计

   • 软删除支持时间点数据状态分析（nerdponx）
     "Analysis might need to know states 'as of' a particular time"
   • 数据是"事实"，删除应记录而非销毁（rorylaitila）
     "Deleting a record = new fact... destroying rows = disappeared fact"

反对软删除的观点

1. 合规与法律限制

   • 隐私法规要求完全删除而非归档（theLiminator）
     "Privacy regulations make soft delete unviable"
   • 客户法律要求彻底删除数据（ntonozzi）
     "Legal requirements that data is fully deleted, not archived"

2. 技术复杂性

   • 模式迁移时需同步处理归档数据（maxchehab）
     "How to migrate archived objects to current schema?"
   • 软删除增加审计日志的不可变性风险（jamilbk）
     "Maintaining structure of deleted data undermined immutable audit trail"

3. 实际需求有限

   • 定期备份+时间点恢复比软删除更实用（iterateoften）
     "The amount of times I have 'undeleted' something are few"
   • 软删除是工程师主导的非用户需求（3rodents）
     "Soft delete isn’t language used by users... should be led by product"

混合方案建议

• 软删除+垃圾回收：离线场景下通过定期GC解决冲突（cyberax）
  "Soft deletes handled like updates... garbage collector hard-deletes later"
• 按删除比例选择策略：少量删除用标记，大量删除用迁移（LorenPechtel）
  "Delete 99%? Move it! Delete 1%? Use a flag"

争议焦点

• 领域依赖性：银行业倾向软删除（MaxGabriel），而合规敏感领域反对（ntonozzi）
• 实现方式：触发器（MaxGabriel）、CDC（jamilbk）、SQLite归档（tracker1）等替代方案被提出