软删除/逻辑删除、硬删除/物理删除：从业务视角重新审视数据库删除策略

关键词：软删除/逻辑删除、硬删除/物理删除、业务语义、数据完整性、deleted_at、关联数据、查询污染、数据膨胀、归档策略。
关键问题：如何根据业务场景（如课程-班级）选择删除策略？软删除如何正确实现（唯一索引、查询过滤）？如何应对软删除导致的数据膨胀与性能问题？如何设计归档机制与清理策略？

一、核心困境：删除，不只是“删除”

想象一个场景：教务系统要下线一门旧课程。此时，你接到一个需求：“删除‘高等数学（2023春）’这门课。”

新手工程师的第一反应，可能就是执行 DELETE FROM course WHERE id = xxx;。简单、直接、任务完成。

但有经验的工程师会立刻警觉，并抛出一系列问题：

1. 历史班级怎么办？ 去年上过这门课的班级记录，难道要一起灰飞烟灭吗？学校的教学档案还需要它。
2. 误删了怎么救？ 如果操作失误，除了求助于几天前的数据库备份（如果有的话），还有更快的办法吗？
3. 谁，在什么时候删的？ 如果后续需要审计，这条记录怎么查？

你看，一个简单的“删除”动作，背后牵连着数据完整性、业务可追溯性和操作安全性三大核心问题。

二、硬删除 vs. 软删除：不是对错，而是权衡

维度	物理删除 (硬删除)	逻辑删除 (软删除)
本质	执行 DELETE 语句，数据从存储引擎中移除。	执行 UPDATE 语句，修改记录的状态标记。
数据状态	真死了。空间可能被复用，数据极难恢复。	休眠了。数据还在，只是默认查询看不见。
恢复成本	极高。需从备份恢复，可能影响整个库。	极低。UPDATE ... SET deleted = 0 即可。
对关联数据影响	灾难性的。若外键有ON DELETE CASCADE，关联数据会被连带清除；若无，则产生孤儿记录（脏数据）。	友好的。关联关系在物理上保持完整，只是逻辑上“失效”。
查询性能	理论上更高。表数据量小，索引更紧凑。	有挑战。需要额外条件 WHERE is_valid=1，处理不当会导致索引失效、全表扫描。
业务语义	毁灭。“这个信息再也不需要存在了”。	归档/失效。“这个信息当前不可用，但需要留档”。

结论一：硬删除适用于“数据生命终结”的场景。

• 临时/中间数据：用户会话（Session）、缓存数据、临时计算结果的存储。
• 可再生的日志数据：某些可被聚合汇总后即可丢弃的原始日志。
• 法律要求的彻底擦除：如用户行使“被遗忘权”，要求彻底删除其个人数据。

结论二：软删除适用于“业务生命终结，但历史价值仍在”的场景。

• 所有核心业务实体：用户、订单、商品、课程、文章。这些是业务的“骨骼”，删除它们通常意味着“停用”或“归档”。
• 需要审计追踪的操作：任何“删除”操作本身都需要被记录以备查。
• 存在强关联的数据：像你的例子，课程与班级。删除课程不应抹杀历史班级的存在。

所以，在大多数To-B（对企业）和To-C（对用户）的核心业务系统中，软删除是默认首选方案。

三、深入软删除：魔鬼在细节中

如果你认为软删除就是“加一个is_deleted字段那么简单”，那就掉以轻心了。下面这些才是实际开发中的“硬骨头”。

1. 实现模式：不止一种选择

在实际开发中软删除的标志可以使用is_valid布尔标记和deleted_at时间戳。在实际中，后者更受青睐：

ALTER TABLE course ADD COLUMN deleted_at DATETIME DEFAULT NULL COMMENT '删除时间，NULL表示未删除';

为什么用时间戳更好？

• 自带删除时间信息：无需额外字段即可审计。
• 唯一索引友好：这是关键！假设课程名name要求唯一。如果只用is_deleted，你无法让“已删除的‘高等数学’”和“新上的‘高等数学’”同时存在。用deleted_at，可以创建唯一索引 UNIQUE KEY uk_name (name, deleted_at)。因为所有未删除的记录deleted_at都是NULL，而NULL在唯一索引中不被视为相等，所以它们可以和平共处。
• 便于数据生命周期管理：可以很容易地找出“已被软删除超过2年的数据”进行归档。

2. 查询的“污染”与优雅处理

这是软删除最大的代价：所有查询都必须记得加上 deleted_at IS NULL 条件。忘掉一次，就会出现“数据幽灵”（本该看不见的数据被查出来了）。

最佳实践：

• ORM层封装（首选）：如果你在使用MyBatis-Plus、Eloquent、Hibernate等ORM框架，利用其提供的全局作用域（Global Scope） 或过滤器（Filter） 功能。

  // MyBatis-Plus 示例：在实体类上标注
  @TableLogic(value = "null", delval = "now()") // 未删除时为null，删除时设置为当前时间
  private LocalDateTime deletedAt;
  

  框架会自动在所有SELECT语句后附加WHERE deleted_at IS NULL。这是最彻底、最安全的解决方案。

• 使用数据库视图（View）：如你输入所说，创建 VIEW valid_course。但对于频繁更新的表，视图可能带来轻微性能开销。

• 规范DAO层：如果没有ORM支持，必须在所有数据访问层（DAO/Mapper）的方法中，显式写明条件。这需要严格的Code Review来保证。

3. 关联查询的“传染性”

当course表软删除后，查询班级时，如果直接JOIN course，就会把已删除课程关联的班级也带出来。

-- 错误：会漏掉班级，因为课程已被过滤
SELECT class.* FROM class
JOIN course ON class.course_id = course.id AND course.deleted_at IS NULL;
-- 问题：如果课程被删，这个班级就查不出来了，即使班级本身是有效的！

正确做法是，查询的过滤条件取决于业务语义：

• “查询所有有效的班级及其课程”：用上面的JOIN ... AND。

• “查询所有班级，并显示其课程信息（如果课程已被删除，则课程信息为NULL）”：使用LEFT JOIN，并在展示时处理课程信息为空的情况。

  SELECT class.*, course.name as course_name
  FROM class
  LEFT JOIN course ON class.course_id = course.id AND course.deleted_at IS NULL;
  

4. 性能与膨胀：必须面对的挑战

软删除的数据永不消失，表会越来越大。

• 索引优化：确保你的查询条件（如 WHERE deleted_at IS NULL AND status = 'PUBLISHED'）能有效利用复合索引。把deleted_at作为复合索引的第一列通常不是好主意，因为它的区分度低（大部分都是NULL）。
• 归档与清理：这是必须要做的事情。归档到历史表是最主流的方式。
  • 定时任务：每周/每月运行一次，将 deleted_at 在一年前的数据迁移到 course_history 表，并从原表删除。
  • 分区表：对于数据量极大的表，可以按时间分区，例如按月分区。软删除只标记，定期 DROP 掉存放旧数据的整个分区，效率极高。
  • 历史库分离：将归档的历史表放到一个单独的、性能较低的数据库实例中，减轻主库压力。

5. 与缓存和搜索引擎的联动

这是高级话题，但你需要有概念。如果你用了Redis缓存课程信息，或用了Elasticsearch提供课程搜索，当课程被软删除后：

• 缓存：必须让对应的缓存失效或更新。
• 搜索引擎：必须发送指令，将这条文档从索引中移除（逻辑删除），而不是直接从数据库里删记录。

四、综合决策框架：我到底该用哪种？

在实际工作中，不要机械地二选一。可以结合使用，形成 “软删除 + 定时硬删除归档” 的策略。

给你的终极建议：

1. 建立团队规范：在新项目启动时，就和团队约定好，默认所有核心表使用deleted_at的软删除模式，并统一使用ORM全局作用域处理。
2. 设计时考虑归档：在设计表之初，就规划好历史表的结构和归档策略。
3. API设计体现语义：对前端或客户端暴露的API，删除接口名用 DELETE /courses/{id} 没问题，但响应体或文档里要说明这是“软删除”。对于“彻底清除”，可以设计为 DELETE /admin/courses/{id}?permanent=true，并严格控制权限。
4. “显示删除”优于“静默删除”：在管理后台，对于已软删除的数据，提供一个“已停用/已归档”的查询tab，让管理员能看到并有机会恢复，这比完全看不见更让人安心。