MySQL 中的逻辑删除，不是真正从磁盘上擦除数据，而是通过一个标记字段（比如 is_deleted 或 del_flag）把某条记录“标为已删除”，后续查询、更新等操作默认忽略它。本质是“假装删了”，实则留痕可溯。
核心设计：加字段 + 统一过滤
最主流、最轻量的设计方式是在原表中新增一个状态字段：
字段名常用：is_deleted、
del_flag或
deleted数据类型推荐：TINYINT(1)（占1字节，语义清晰，支持0/1），不建议用 BOOL（MySQL 中 BOOL 是 TINYINT 的别名，但易引发误解） 默认值必须设为 0（代表“未删除”），避免插入时漏填导致误判 所有业务查询 SQL 必须显式带上
WHERE is_deleted = 0条件——这是逻辑删除生效的前提
字段值怎么定义更合理
基础方案用 0/1 足够，但进阶场景可增强语义：
纯二值：0 → 有效；1 → 已删除（开发最简单，ORM 如 MyBatis-Plus 默认支持） 带时间戳：新增deleted_at DATETIME NULL字段，删除时设为
NOW()，既能标记状态，又保留删除时间，便于审计或定时归档 多状态扩展：用 TINYINT 存 0（正常）、1（已删除）、2（草稿）、3（待审核）等，适合有复杂生命周期的业务表
必须注意的几个坑
逻辑删除看着简单，实际落地容易踩雷：
唯一约束冲突：比如username设了 UNIQUE，逻辑删除后仍占着值，新用户无法重名注册。解法有两种：① 改用联合唯一索引
(username, is_deleted)，让已删记录不参与唯一校验；② 插入前查一遍
WHERE username = ? AND is_deleted = 0索引失效风险：如果常按
is_deleted = 0查询，建议给该字段单独建索引，或将其加入复合索引的左侧（如
INDEX(is_deleted, created_at)） 全表扫描隐患：没加
is_deleted = 0条件的旧 SQL（尤其是统计类、导出类脚本）会查出已删数据，可能引发资损或隐私泄露，上线前务必全局扫描并加固
要不要建备份表？
极少数场景（如合规强要求“删除即不可见”，且历史数据量极大影响查询性能）会采用物理分离方案：把逻辑删除的数据
INSERT INTO xxx_archive SELECT ...后再
DELETE FROM xxx。但这已不属于标准逻辑删除，而是“冷热分离+软删结合”，维护成本高，一般项目不推荐。
