MySQL触发器无法拦截DELETE并转为UPDATE，因触发表在触发器中禁止修改；可行方案是在BEFORE DELETE中将OLD.*插入日志表备份，但需注意时间函数、操作人识别、约束兼容及批量删除回滚风险。
触发器里不能“拦截DELETE并转为UPDATE”
MySQL 触发器无法阻止原 DELETE 语句执行，更不能把它“改写”成 UPDATE。你写一个 BEFORE DELETE 触发器，里面尝试 UPDATE users SET deleted_at = NOW()，会直接报错：Can't update table 'users' in stored function/trigger。这是 MySQL 的硬性限制——触发表（即被删的表）在触发器中禁止修改。所谓“自动软删除”，从底层机制上就走不通。
想备份删前数据，只能用INSERT INTO log + OLD.*
真正可行的做法，是在 BEFORE DELETE 触发器中把即将被删的行存到另一张日志表里。前提是这张日志表和原表结构兼容，且你有写权限：
- 日志表必须提前建好，字段尽量覆盖
OLD.*所需列，比如log_users_backup(id, name, email, deleted_at, deleted_by) - 触发器内只做
INSERT INTO log_users_backup SELECT OLD.id, OLD.name, OLD.email, NOW(), USER()，不碰原表 - 注意：
OLD.*在BEFORE DELETE中可用，但AFTER DELETE中已不可读，必须用前者 - 如果原表字段多、含 BLOB 或 JSON，日志表对应字段类型要严格匹配，否则插入失败会导致整个
DELETE回滚
备份字段值易被忽略的三个坑
你以为把 OLD.* 插进去就完事了？实际常踩这些坑：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
NOW()和CURRENT_TIMESTAMP在触发器中返回的是语句开始时间，不是触发器执行时刻——若事务里有延迟操作，时间可能不准 -
USER()返回的是连接用户（如'app@10.0.1.5'），不是应用层传来的操作人ID；真要记操作人，得靠应用层把@operator_id设为会话变量再读取 - 如果原表有自增主键、唯一约束或外键，日志表不能简单照搬；备份表建议去掉所有约束，只保留基础字段和索引（如按
deleted_at加索引）
批量删除时备份会失效或漏数据
触发器是逐行触发的，但 DELETE FROM users WHERE status = 'inactive' 这种批量删，只要其中某一行触发器出错（比如日志表磁盘满、字段超长），整条 DELETE 就会回滚——业务感知是“删不动”，而不是“部分备份成功”。更麻烦的是：
- 中间件（如 ShardingSphere）、ORM（如 SQLAlchemy 的 bulk_delete_mappings）或代理（如 ProxySQL）可能把批量删重写为多条单行删，也可能合并为一条，行为不可控
- 如果应用没关 AUTOCOMMIT，又在事务里删 100 行，触发器会插 100 条日志，但日志表写入慢会拖累主事务响应
- 备份逻辑不在事务内原子化：日志表插入成功但主表删失败（极罕见），或反之，都可能造成数据不一致
真正可靠的软删除+备份，得由应用层统一控制流程，触发器只承担最轻量的补全动作，比如记录时间、用户、IP——别让它扛主逻辑。
