mysql如何实现数据软删除_mysql项目数据管理

软删除不能直接用delete语句，因其不可逆且破坏审计、恢复与关联一致性；本质是逻辑标记（如is_deleted=1）加全局查询过滤，须统一在orm层拦截，禁用物理delete权限，并为is_deleted建索引以保障性能与唯一性逻辑。

软删除为什么不能只靠 DELETE 语句

直接执行 DELETE FROM users WHERE id = 123 就没了，不可逆，审计、恢复、关联数据一致性全崩。软删除本质是“逻辑标记+查询过滤”，不是真删。

常见错误现象：加了 is_deleted 字段但忘了在所有 select 里加 WHERE is_deleted = 0，导致前端突然显示“已删除用户”；或者 ORM 查询默认没启用软删除拦截，查出脏数据。

• 必须统一收口查询逻辑，不能靠每个开发手写 WHERE
• is_deleted 推荐用 TINYINT(1) 或 Boolean（mysql 实际存为 TINYINT），别用字符串如 'yes'/'no'，索引效率低且易拼错
• 删除操作应改写为 UPDATE users SET is_deleted = 1, deleted_at = NOW() WHERE id = ? AND is_deleted = 0，加条件防止重复软删或误操作

MySQL 触发器能自动处理软删除吗

不能依赖触发器实现可靠软删除。触发器在 DELETE 语句触发时才运行，而你根本不想让 DELETE 语句执行——它会绕过你的标记逻辑，直接物理删除。

更糟的是：触发器无法阻止原 DELETE 行为（MySQL 不支持 BEFORE DELETE 中中止操作），只能补救，但行已经没了。

• 正确做法是：应用层彻底禁用 DELETE 权限，或通过数据库代理/中间件拦截 DELETE 语句并报错
• 如果硬要用触发器，仅限于辅助场景，比如自动填充 deleted_by 字段，但主逻辑必须在业务代码里
• 注意触发器不生效于批量 DELETE 或外键级联删除，风险不可控

mybatis / laravel / django 怎么统一拦截查询

ORM 层才是软删除落地的关键位置，数据库只是存储配合。各框架有成熟方案，但配置点容易漏。

MyBatis：用 @SelectProvider 或通用 Mapper 的 Example 拦截，但更推荐在 BaseMapper 的 selectList 方法里默认追加 AND is_deleted = 0 条件；动态 SQL 中所有 <where></where> 块开头加 AND is_deleted = 0，否则 WHERE 1=1 后接 AND 会语法错误。

Laravel：模型开启 SoftDeletes trait 后，find()、get() 自动过滤，但 withTrashed() 和 onlyTrashed() 必须显式调用才能查到软删数据——别在管理后台列表里漏掉 withTrashed() 导致删了看不到。

Django：用 django-model-utils 的 SoftDeletableModel，但要注意 objects manager 默认已过滤，若需查全部得用 all_objects；外键关系默认不级联软删，得手动重写 delete() 方法。

软删除后 count(*) 和索引还能信吗

加了 is_deleted 字段后，如果没给它建索引，SELECT COUNT(*) FROM orders WHERE is_deleted = 0 可能全表扫描，尤其千万级订单表，慢得离谱。

更隐蔽的问题：UNIQUE 约束对软删数据依然生效。比如邮箱字段设了 UNIQUE，用户 A 软删后，新用户 B 注册同邮箱会因唯一键冲突失败——这通常不是期望行为。

• 必须为 is_deleted 单独建索引，或与高频查询字段组成联合索引，如 (is_deleted, created_at)
• 对需要“逻辑唯一”的字段（如邮箱），改用函数索引（MySQL 8.0+）：CREATE UNIQUE INDEX uk_email_active ON users (email) WHERE is_deleted = 0
• COUNT(*) 在大表上慎用，考虑用统计表或缓存值替代实时计算

软删除看着简单，真正落地时最常翻车的不是技术实现，而是跨团队协作时“谁负责加 WHERE is_deleted = 0”没人认领，或是迁移老表时忘了补 deleted_at 默认值，导致一堆 NULL 值干扰判断。