逻辑删除应使用UPDATE修改状态字段而非DELETE物理删除，因后者导致数据不可恢复、审计困难、关联断裂；须全局统一过滤status=1，建索引、用视图/ORM作用域、冗余状态列保障一致性。
为什么不能直接用 DELETE 语句删数据
逻辑删除本质是“假装删了”，实际数据还在表里。直接执行 DELETE FROM users WHERE id = 123，数据就真没了，恢复成本高、审计难、关联数据可能断链。尤其在有外键、历史统计、用户行为追踪的场景下，物理删除会破坏数据完整性与业务可追溯性。
常见错误现象：DELETE 后发现报表对不上、管理员找不到操作记录、前端突然报“用户不存在”但日志显示刚被禁用——其实是误删而非禁用。
实操建议：
- 建表时就预留状态字段，比如
status（TINYINT或ENUM），默认值设为1（启用） - 所有写操作必须走
UPDATE改状态，而不是DELETE - 给
status字段加索引（尤其当表数据量 >10 万行时），否则全表扫描拖慢查询
WHERE 条件里漏写 status = 1 就等于裸奔
逻辑删除生效的前提，是每次查数据都主动过滤掉已“删除”的记录。一旦在 SELECT、JOIN 或应用层 ORM 查询中漏掉 AND status = 1，就会把已禁用的用户、已下架的商品、已注销的订单全暴露出来——这是最常踩的坑，且上线后极难排查。
使用场景：后台列表页、API 接口、定时任务读取用户数据、报表 SQL 脚本。
实操建议：
- 把通用过滤条件抽成视图，比如
CREATE VIEW active_users AS SELECT * FROM users WHERE status = 1，后续只查视图 - ORM 层（如 Django 的
QuerySet、Laravel 的global scopes）配置默认作用域，自动追加status = 1 - 禁止在任意地方手写裸
SELECT * FROM users；DBA 应在 SQL 审核规则里拦截无status过滤的SELECT
status 字段选 INT 还是 ENUM？别小看这点差异
status 类型选错，会影响可读性、迁移成本和查询性能。用 VARCHAR 存 “active”/“deleted” 看似直观，但索引效率低、拼写易错、排序不可控；用 ENUM 虽紧凑，但在 MySQL 5.7+ 中修改枚举值需锁表，线上不敢动。
实操建议：
- 首选
TINYINT UNSIGNED，范围够用（0–255），支持快速比较和索引，也方便扩展新状态（比如 0=deleted, 1=active, 2=pending_review） - 用注释明确每个值含义：
status TINYINT DEFAULT 1 COMMENT '0: deleted, 1: active, 2: locked' - 应用层定义常量映射，比如 Python 里写
STATUS_ACTIVE = 1，避免硬编码数字
软删除关联数据时，ON DELETE CASCADE 不起作用
逻辑删除不是数据库原生机制，所以外键的 ON DELETE CASCADE 对 UPDATE status 完全无效。比如订单表关联用户表，用户“逻辑删除”后，订单仍指向该用户 ID，但若没同步处理订单状态，就可能出现“已注销用户下的有效订单”这种业务矛盾。
性能影响：手动维护关联状态（如批量更新订单的 user_status 字段）会带来额外 I/O 和锁竞争。
实操建议：
- 关键关联字段加冗余状态列，比如订单表里存
user_status，和用户表保持异步一致（用应用层事务或 MQ 补偿） - 查询时用
LEFT JOIN+ON u.id = o.user_id AND u.status = 1，确保只连上有效用户 - 定期跑校验脚本，检查是否存在
order.user_id对应的users.status != 1，及时告警
状态位逻辑看着简单，真正落地时最麻烦的是“一致性”——不是某一条 SQL 写对就行，而是所有读、写、关联、导出、备份脚本都得记住它存在。漏一处，数据就裂开一道缝。
