MySQL 8.0 的 BEFORE DELETE 触发器无法实现软删转硬删，因其禁止在触发器内执行 DELETE 操作、不支持事务级回滚，且无法控制物理删除逻辑；正确做法是用存储过程封装条件判断与执行逻辑。
MySQL 8.0 的 BEFORE DELETE 触发器无法把软删除“自动转为”硬删除——它根本做不到拦截并替换 DELETE 行为，更不能在触发器里执行物理删除后还假装没删。
为什么 BEFORE DELETE 触发器不能实现“软删转硬删”
软删除的本质是阻止物理删除、改写状态字段；而“软删转硬删”意味着：当某条记录已标记为软删除（如 deleted_at IS NOT NULL），后续再对它发 DELETE 时，希望数据库直接物理删掉。这个逻辑听起来合理，但 MySQL 触发器机制不支持。
- MySQL 不允许在
BEFORE DELETE触发器中执行DELETE FROM ... WHERE id = OLD.id—— 会报错Can't modify table 'xxx' in stored function/trigger - 你也不能在触发器里
ROLLBACK当前语句（MySQL 不支持事务级语句中断） -
AFTER DELETE更不行：行已经没了，OLD不可用，补救无从谈起 - 所谓“自动转”，实际需要的是条件分支逻辑，但触发器不是程序语言，没有
IF ... ELSE控制物理删除与否的能力
真正可行的替代方案：用存储过程封装删除逻辑
把“判断是否已软删 → 决定 UPDATE 还是 DELETE”的逻辑移到存储过程中，由应用调用该过程，而非直连 DELETE 语句。
- 创建存储过程
soft_or_hard_delete_user，入参为user_id - 先
SELECT deleted_at INTO @d FROM users WHERE id = user_id - 若
@d IS NOT NULL，执行DELETE FROM users WHERE id = user_id - 否则执行
UPDATE users SET deleted_at = NOW() WHERE id = user_id - 应用层只调用
CALL soft_or_hard_delete_user(123)，彻底屏蔽原生DELETE
注意：该过程需搭配权限控制——回收普通用户对 users 表的 DELETE 权限，只授予执行该过程的权限。
如果坚持用触发器，只能做单向辅助，不是“转换”
触发器唯一安全的用途，是在 BEFORE DELETE 中检查状态，并抛异常阻止误操作，或填充审计字段：
- 比如检测到
OLD.deleted_at IS NOT NULL时，SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Hard delete not allowed via DELETE statement' - 或仅自动设置
deleted_by字段：UPDATE users SET deleted_by = USER() WHERE id = OLD.id（但必须确保该 UPDATE 不再触发嵌套触发器） - 这种做法不改变 DELETE 结果，只是加约束或日志，和“软删转硬删”目标无关
外键、级联、批量操作会让触发器彻底失效
哪怕你绕过限制写出看似工作的触发器，以下场景仍会导致行为失控：
-
DELETE FROM users WHERE id IN (1,2,3)：触发器对每行单独触发，但无法感知“这批里有已软删的” - 外键设了
ON DELETE CASCADE：子表行被直接删，不走任何触发器 - 使用
TRUNCATE TABLE：不触发任何触发器，且无法被拦截
这些不是边缘情况，而是生产环境高频操作。依赖触发器做“自动转换”，等于在关键路径埋雷。
最易被忽略的一点：软删除字段（如 deleted_at）一旦被用于条件分支，所有查询、索引、ORM 映射、备份恢复脚本都必须同步适配——触发器本身解决不了跨层一致性问题。
