不能用触发器在 BEFORE DELETE 中实现多表级联软删除，因MySQL 5.7禁止在BEFORE DELETE中UPDATE关联表，会报错1442或导致数据不一致；正确路径是禁用DELETE权限，统一通过BEFORE UPDATE触发器标记is_deleted=1并更新deleted_at/deleted_by。
不能用触发器在 BEFORE DELETE 中实现多表级联软删除。MySQL 5.7 的触发器机制不支持这种操作，强行尝试会报错或导致数据不一致。
为什么 BEFORE DELETE 里改 UPDATE 行不通
你可能想在用户表的 BEFORE DELETE 触发器里写：UPDATE orders SET is_deleted = 1 WHERE user_id = OLD.id。这看似合理，但 MySQL 会直接报错：ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger——只要 orders 和 users 存在外键关联（哪怕只是引用），这个限制就生效。
即使绕过外键、手动删索引、用子查询硬套，也会遇到更隐蔽的问题：
- 原
DELETE语句仍会继续执行，软删后立刻被物理删掉 - 触发器返回 0 rows affected，应用层误以为删除成功，实则数据已丢失
- 事务回滚时，
UPDATE不会回滚，造成状态错乱
真正能落地的软删除路径：全靠 BEFORE UPDATE + 权限控制
逻辑删除的本质是“把用户的删意图，转成一次带标记的更新”。这个动作天然属于 UPDATE，不是 DELETE。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
正确做法是：
- 撤掉所有应用账号对目标表的
DELETE权限：REVOKE DELETE ON mydb.users FROM 'app_user'@'%' - 在
users表上建BEFORE UPDATE触发器，只响应is_deleted = 1的更新 - 触发器内检查：
IF OLD.is_deleted = 0 AND NEW.is_deleted = 1 THEN SET NEW.deleted_at = NOW(), NEW.deleted_by = @current_user - 对关联表（如
orders、profiles）做同样处理：也禁用它们的DELETE，统一走BEFORE UPDATE标记软删
这样，整个链路可控、可审计、事务安全。没有哪一步依赖“拦截 DELETE”这种不可靠机制。
多表联动时最容易忽略的三个点
实际部署中，以下三点常被跳过，却直接决定软删除是否可靠：
-
SELECT查询必须显式加WHERE is_deleted = 0—— 触发器不改查询行为，漏加条件等于没软删 - 所有关联表的
is_deleted字段要建索引，否则WHERE is_deleted = 0会全表扫描 - 应用层传参时，
@current_user必须由连接池或中间件注入，不能靠客户端伪造；否则deleted_by字段毫无意义
别指望触发器替你兜底。它只管“改写一次更新”，其余全部得靠权限、索引、查询习惯和应用配合。缺一不可。
