不能用触发器实现可靠软删除，因MySQL的BEFORE DELETE触发器无法中止原DELETE语句，且禁止修改触发表；物理删除仍会执行，补救无效；多表软删除必须由应用层在统一事务中显式控制UPDATE。
不能用触发器实现可靠的软删除，更不能靠它做“多表联合关联软删除”。触发器在 DELETE 语句执行时才被唤起，而软删除的本质是**阻止物理删除、改写状态字段**——这一步必须发生在 DELETE 执行之前，且需中止原操作。MySQL 的 BEFORE DELETE 触发器无法取消语句，只能补救；等它运行完，行已经从引擎层标记为删除，OLD 数据可能不可靠，甚至已丢失。
为什么 BEFORE DELETE 触发器填 deleted_at 却仍被物理删了
因为触发器不拦截语句执行。你写：
CREATE TRIGGER tr_users_soft_delete BEFORE DELETE ON users FOR EACH ROW BEGIN UPDATE users SET deleted_at = NOW(), status = 'deleted' WHERE id = OLD.id; END;
这段代码实际会：先尝试更新 users 表里同一行（违反 MySQL “不能在触发器中修改触发表”规则），直接报错 Can't update table 'users' in stored function/trigger...；即使绕过（比如用 INSERT INTO log + IGNORE），原 DELETE 仍会继续执行，最终物理删掉该行。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- MySQL 不支持在触发器中 abort 当前语句，
RETURN或EXIT无效 - 想“假装删”，必须让应用层根本发不出
DELETE，而是统一走UPDATE ... SET deleted_at = NOW() - 任何依赖触发器自动转换
DELETE → UPDATE的方案，在批量删除、外键级联、或代理层透传时都会失效
如果坚持用触发器辅助软删除，只限于补充字段
仅可在业务层已确保不发 DELETE 的前提下，用触发器补全审计字段，例如自动记录谁删的、删前快照等。但主逻辑必须由应用控制：
- 应用层禁止对软删除表授予
DELETE权限，只给SELECT, UPDATE - 触发器可写成：
BEFORE UPDATE ON users FOR EACH ROW IF NEW.deleted_at IS NOT NULL THEN SET NEW.deleted_by = USER(), NEW.deleted_ip = @client_ip; END IF; - 注意：触发器不生效于
UPDATE ... WHERE批量更新（除非每行都命中），也不捕获来自中间件或备份恢复的变更 - 不要在触发器里查子表或写日志表——这会拖慢主表
UPDATE，且失败时可能导致主操作也失败
多表关联软删除必须由应用层统一事务控制
例如删一个用户并软删其订单、地址、头像记录。这不是触发器能安全兜住的场景：
- 触发器无法保证跨表软删除的原子性：若订单表
UPDATE成功、地址表失败，数据就撕裂了 - MySQL 触发器不参与外层事务回滚——哪怕你在事务里
UPDATE users，触发器内写的日志表变更也不会随ROLLBACK撤销 - 正确做法是：应用代码显式执行一组
UPDATE，全部放在同一个事务里，顺序明确（如先子表后主表），失败则整体回滚 - 避免用子查询动态决定删哪些表——执行计划不可控，容易锁表；应预先确定关联路径，硬编码表名和字段
真正麻烦的不是语法怎么写，而是软删除带来的查询污染：所有 SELECT 都得加 WHERE deleted_at IS NULL，索引失效风险高，历史数据归档困难。这些设计权衡，触发器一句也帮不上忙。
