上一篇
数据库怎么逻辑删除
库逻辑删除可通过添加“is_deleted”等标记字段实现，更新该字段值而非
库的逻辑删除是一种重要的数据管理技术，它通过标记而非实际移除的方式来处理不再需要展示或使用的记录,以下是关于如何实现和使用逻辑删除的详细说明：
| 方面 | 描述 | 示例/细节 |
|---|---|---|
| 定义 | 不真正删除数据行，而是设置特定字段表示该记录已被“删除”。 | 常见做法是在表中增加如 is_deleted（布尔型）、status（枚举值）或 deleted_at（时间戳）等字段来标识数据的删除状态。 |
| 核心目的 | 保留历史数据以便审计、恢复；避免物理删除导致的外键约束破坏和性能损耗。 | 适用于需追溯操作记录的场景（如财务系统）、需定期清理但可能误删的情况，以及存在多表关联关系的复杂系统中。 |
| 实现方式 | 添加标记字段：例如新增 deleted=0/1，默认值为0代表未删除，更新为1时视为已删除；修改状态值：用枚举类型区分不同状态（如 “active”, “deleted”）； 触发器辅助：创建数据库触发器自动维护标记字段的值。 |
MyBatis-Plus框架支持通过注解 @TableLogic 自动转换删除操作为更新标记字段的动作，简化开发流程。 |
| 配置示例 | 在配置文件中指定全局参数： | application.yml 中设置 logic-delete-field: flag, logic-delete-value: 1, logic-not-delete-value: 0，使所有查询默认过滤掉已标记删除的记录。 |
| 优势 | 数据可恢复性高：只需重置标记即可还原数据； 维护完整性：保留关联关系的完整性； 性能优化：减少索引重建频率，尤其适合高频增删场景。 |
对比物理删除，逻辑删除对数据库IO影响更小，且无需担心误删后难以挽回的问题。 |
| 注意事项 | 查询复杂度增加：所有读操作必须携带过滤条件（如 WHERE is_deleted=0）；唯一性约束冲突：若原表有唯一索引，需调整为组合索引（含删除标记），避免新数据与旧数据的键值重复； 存储空间占用：长期积累大量无效数据可能导致库容膨胀。 |
解决方案包括设计联合唯一索引、定期归档冷数据，或采用分区表策略分离活跃与非活跃数据集。 |
| 工具支持 | ORM框架（如MyBatis-Plus）提供内建支持，自动处理逻辑删除逻辑，减少手写SQL错误风险。 | 开发者只需关注业务逻辑，框架底层会自动添加相应的过滤条件和更新语句。 |
在实际开发中，建议根据业务需求权衡利弊：对于敏感信息或合规要求严格的场景，可结合物理删除与逻辑删除双重机制；而对于需要长期留存审计轨迹的系统，则优先选择纯逻辑删除方案,定期清理过期的逻辑删除数据也是必要的运维措施。
相关问答FAQs
Q1: 为什么不能直接用物理删除代替逻辑删除？
A: 物理删除会永久移除数据，导致无法追溯历史变更、恢复误删内容，并且可能破坏与其他表的外键关联，而逻辑删除仅改变数据状态，既能满足业务上的“删除”需求，又能保留原始记录用于后续分析或恢复，电商平台的用户退货流程中，订单不会被真正删除，而是标记为已取消,以便客服核查问题订单。
Q2: 如何处理逻辑删除后的唯一性约束冲突？
A: 可以将唯一约束字段与删除标记组合成联合唯一索引，当某条记录被逻辑删除时，将其删除标记设为NULL（或其他特殊值），此时该记录不再参与唯一性检查，从而允许插入具有相同主键的新数据，另一种方法是添加时间戳字段（如 delete_time），并与原唯一字段共同构成复合索引，确保批量操作时的效率与准确性
