不能，触发器无法将UPDATE转为DELETE，但可在BEFORE UPDATE中实现逻辑删除：如is_deleted由0变1时设deleted_at，或对已删记录禁止修改并报错；同时须禁用DELETE权限并规范查询加WHERE is_deleted=0。
触发器能拦截 UPDATE 转 DELETE 吗？不能，但可以模拟逻辑删除行为
MySQL 触发器无法真正“拦截”一条 UPDATE 语句并把它变成 DELETE——SQL 执行引擎在解析阶段就决定了语句类型，触发器只在语句执行过程中响应事件。但你真正需要的，其实是：当某条记录被标记为“已删除”（比如 status = 'deleted' 或 is_deleted = 1），自动跳过物理删除、改走软删逻辑。这完全可行，关键是别指望触发器去“转换语句类型”。
BEFORE UPDATE 触发器里改字段值，是最直接的软删控制点
多数逻辑删除场景本质是：用户执行 UPDATE table SET status = 'deleted' WHERE id = 123，你希望这条记录后续查询默认不出现，且不允许被再次 UPDATE 或 INSERT 覆盖。这时 BEFORE UPDATE 是唯一能干预本次修改的时机：
- 检查是否正在把
is_deleted从0改成1；如果是，可额外设置deleted_at = NOW()、deleted_by = @current_user等审计字段 - 若发现
OLD.is_deleted = 1且NEW.status有变更，可抛出错误阻止误操作：SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Cannot modify deleted record'; - 避免在触发器里做
INSERT INTO log_table这类额外写入——高并发下容易成为瓶颈
示例：
CREATE TRIGGER tr_users_before_update BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.is_deleted = 0 AND NEW.is_deleted = 1 THEN
SET NEW.deleted_at = NOW();
END IF;
IF OLD.is_deleted = 1 AND (OLD.name != NEW.name OR OLD.email != NEW.email) THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Read-only for deleted users';
END IF;
END;
DELETE 语句必须被显式禁用，否则逻辑删除形同虚设
光靠 UPDATE 控制不够。如果用户直接执行 DELETE FROM users WHERE id = 123，触发器根本不会触发（BEFORE DELETE 可以捕获，但不能“转成 UPDATE”）。所以必须双管齐下：
- 撤销应用账号对表的
DELETE权限：REVOKE DELETE ON mydb.users FROM 'app_user'@'%'; - 如需保留 DBA 清理能力，可建专用视图或存储过程封装软删逻辑，而非开放原表
- 不要依赖
BEFORE DELETE去做UPDATE操作——它会成功执行，但违反直觉：用户看到DELETE返回 “0 rows affected”，却没意识到数据还在，极易引发后续 bug
WHERE 条件漏掉 is_deleted = 0 是最常踩的坑
所有 SELECT、UPDATE、JOIN 操作，只要没显式排除已删除记录，就会把软删数据卷进来。这不是触发器能解决的，得靠开发规范和代码层约束：
- 通用查询必须加
WHERE is_deleted = 0，连COUNT(*)都不能例外 - ORM 如 Laravel Eloquent 或 Django ORM 有软删扩展，但它们只是帮你自动拼
WHERE，底层仍是普通UPDATE，仍需配合触发器补审计字段 - 报表类查询可能需要查全量（含已删），此时应明确使用
WITH_DELETED视图，而不是临时去掉条件
这事没法全自动兜底，数据库不认业务语义。触发器只管住“改状态”那一刻，后面怎么查、怎么联、怎么聚合，全看人写 SQL 时有没有绷着那根弦。
