MySQL触发器无法阻止DELETE并转为软删除，因BEFORE DELETE中OLD只读且禁止中断或UPDATE原表，AFTER DELETE时行已不可用；唯一可靠方式是权限管控或应用层拦截。
不能用触发器“防止”DELETE并自动转为软删除——MySQL不支持在BEFORE DELETE中中止或改写原操作，且AFTER DELETE里行已不存在，无法UPDATE标记字段。
BEFORE DELETE触发器无法拦截或改写DELETE语句
MySQL的BEFORE DELETE触发器能访问OLD数据，但**不允许抛出错误中断执行**，也不允许执行UPDATE原表（会报错：Can't update table 't1' in stored function/trigger because it is already used...）。你写SET OLD.is_deleted = 1是非法的——OLD是只读伪记录，不能赋值。
- 想靠
BEFORE DELETE把DELETE FROM users WHERE id=123悄悄变成UPDATE users SET is_deleted = 1 WHERE id = 123？语法上就不允许 - 哪怕只尝试
INSERT INTO audit_log记一笔，也解决不了“行被删了”这个事实 - 外键级联DELETE、批量
DELETE、或应用直连执行的DELETE，都绕过你的控制逻辑
AFTER DELETE触发器拿到的是空壳，没法补救
AFTER DELETE触发时，原行在InnoDB中已被标记为可回收（甚至已释放），OLD虽可读，但**你不能再对原表做任何DML操作来“恢复”它或打标**。此时执行UPDATE users SET is_deleted = 1 WHERE id = OLD.id会报错或静默失败（取决于SQL模式）。
- 常见误写：
INSERT INTO archive SELECT * FROM users WHERE id = OLD.id—— 这条SELECT可能查不到数据，因为行物理上已不可见 - 即使查到了，也说明DELETE还没真正提交，那更不该依赖这种竞态行为
- 归档动作若跨库（如写入
archive_db.users），还会触发ERROR 1442（不能在触发器里更新其他表，除非显式声明为READ COMMITTED且目标表无触发器）
真正可控的软删除必须从源头堵住DELETE
唯一可靠路径是：让DELETE语句根本执行不了。这不是触发器的事，是权限与架构的事。
- 收回业务账号的
DELETE权限：REVOKE DELETE ON mydb.users FROM 'app_user'@'%' - 在数据库代理层（如ProxySQL、ShardingSphere）或ORM层拦截
DELETE语句，统一转成UPDATE ... SET is_deleted = 1, deleted_at = NOW() - 如果非要用触发器辅助，仅限
BEFORE UPDATE自动填充审计字段：SET NEW.updated_at = NOW(), NEW.updated_by = USER()，但软删除判断和执行必须由应用代码完成 - 所有软删除操作，必须显式带
WHERE is_deleted = 0条件，避免误更新已归档数据
最容易被忽略的一点：软删除不是加个字段就完事，SELECT *默认会拉出所有is_deleted = 1的脏数据，每个查询都得补AND is_deleted = 0——这靠触发器完全管不了，得靠ORM scope、视图封装或SQL模板强制约束。
