软删除不能直接用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 值干扰判断。
