日期:2026-07-11
难度:简单
标签:#面试 #MySQL #逻辑删除 #数据治理 #VIP
一句话答案
逻辑删除通过状态或 deleted_at 标记数据不可见,记录仍保留;物理删除执行 DELETE 真正移除记录,最终由存储引擎回收空间。
面试口语版
逻辑删除适合需要审计、恢复、历史关联和异步清理的业务,查询统一加 deleted_at IS NULL。它的代价是表持续膨胀、所有查询都要防止漏条件、唯一约束会更复杂,而且被删除数据仍占索引和备份。物理删除能真正清理数据并简化查询,但恢复困难,大批量 DELETE 会产生锁、undo、redo 和复制压力。实际常用“先逻辑删除、保留期后分批物理清理”,对隐私删除还要同步处理备份、缓存、搜索和对象存储。
原理拆解
| 对比项 | 逻辑删除 | 物理删除 |
|---|---|---|
| 数据是否保留 | 保留并标记 | 删除记录 |
| 恢复 | 容易 | 依赖备份/日志 |
| 查询复杂度 | 必须过滤删除态 | 简单 |
| 存储 | 持续占用 | 可逐步回收 |
| 审计 | 方便 | 需审计表/日志 |
关键细节
- 建议使用可审计的
deleted_at、deleted_by,而不只有模糊的布尔值。 - MySQL 唯一索引包含 NULL 的语义会影响“删除后允许重建同名对象”的设计。
- DELETE 后文件未必立即变小,空间可能只在表空间内复用。
面试官追问
- 逻辑删除如何实现唯一约束?
- 如何防止查询漏加删除条件?
- 大表如何分批物理清理?
高分补充
逻辑删除不是合规删除的终点;数据生命周期必须覆盖所有副本和下游系统。
学习清单
- 准备“逻辑删除 + 延迟物理清理”的生命周期方案。