1、定义1.1 逻辑删除不真正删除数据而是通过一个标记字段如is_deleted、deleted_at表示该记录已被“删除”。查询时过滤掉这些记录。1.1.1 常见实现时间戳字段推荐deleted_at DATETIME NULLNULL 表示未删除。既能表达状态又能记录删除时间还能顺带解决唯一索引问题布尔字段is_deleted TINYINT(1) DEFAULT 0。归档表删除时把行搬到xxx_history/xxx_archive主表物理删。这是逻辑删除和物理删除的折中主表保持精简历史可追溯。1.1.2 优点数据可恢复误删可找回保留历史记录便于审计、追溯不影响关联数据外键关系仍存在对业务代码侵入较小只需在查询中加过滤条件1.1.3 缺点表中数据量持续增长影响查询性能所有查询都要带过滤条件容易遗漏唯一索引与逻辑删除冲突如用户名唯一删除后无法复用需要额外存储空间1.2 物理删除直接从数据库中将记录移除数据不可恢复。1.2.1 常见实现DELETE FROM users WHERE id 100;1.2.2 优点释放存储空间表数据量小查询性能好无额外过滤条件逻辑简单唯一约束不会冲突1.2.3 缺点数据不可恢复误删风险高破坏历史记录不利于审计可能影响外键关联数据需级联删除或置空高并发下可能产生锁竞争2、对比维度物理删除DELETE逻辑删除Soft Delete数据留存行被移除仅 binlog/备份中可找回行仍在表中靠字段标记恢复能力难需 binlog 闪回或从备份恢复极易改个字段值即可查询成本无额外开销所有查询都要带where deleted 0漏一处就出脏数据存储与性能表体积可控表持续膨胀索引变大冷热数据混在一起拖慢查询唯一约束天然可用经典坑删了的用户手机号/邮箱不能重新注册外键关联可能误删或触发级联关联行依然存在历史快照完整合规满足被遗忘权/数据最小化数据仍在库里未必满足删除要求实现成本零需规范、ORM 拦截、归档机制配套3、适用场景3.1 推荐逻辑删除软删场景需要数据可恢复订单、客户账号、商品、文章、评论误删可以撤回。审计、对账、追溯财务数据、业务流水法规要求留存一段时间数据不能直接删掉。业务有回收站功能网盘、后台管理系统支持查看 / 恢复已删除记录。业务存在删除后溯源需求排查用户操作、纠纷取证。缺点表越来越大查询索引效率慢慢下降需要定期归档已软删数据到归档表。3.2 推荐物理删除硬删场景数据不需要任何恢复无审计要求临时日志、临时会话、缓存表、过期临时任务。数据量极大存储压力高海量埋点日志、临时中间表保留无用数据会拖慢查询。隐私合规强制要求彻底清除用户申请注销法规要求彻底删除个人信息GDPR / 个人信息保护法场景单纯软删可能不满足合规。简单小型表没有回滚需求追求简单不想每次查询都加过滤条件。注意很多场景用户注销只做逻辑删除不满足隐私合规合规场景要物理删除或者脱敏后物理删除。4、实践建议成熟系统通常是两者结合默认逻辑删除定期归档业务表逻辑删除后台定时任务把deleted_at超过 30/90 天的记录物理迁移到归档表再物理删除。处理唯一索引冲突把唯一索引改为(字段, deleted_at)复合唯一索引删除时把deleted_at写成删除时间戳而不是固定值如 1这样同一个值删除多次也不冲突。谨慎选择标志位用deleted_at时间戳可知道何时删除优于is_deleted0/1。查询别忘过滤这是逻辑删除最大的坑——漏写条件就把已删除数据返回了。务必依赖 ORM 全局过滤或数据库视图而不是靠人肉记得加WHERE。级联问题逻辑删除主表记录后其关联的子表记录怎么办要考虑是否也需要逻辑删除否则会出现孤儿数据。5、总结有恢复/追溯需求的业务数据用逻辑删除量大无价值或合规要求彻底抹除的数据用物理删除两者结合 定期归档是大型系统的常见解法。