BEFORE UPDATE触发器通过SIGNAL中止非法修改，AFTER UPDATE无法回滚；须检查OLD/NEW值差异、禁用子查询、冗余权限字段、避免跨表查与写日志，并覆盖所有校验分支。

BEFORE UPDATE触发器如何拦截非法修改

要阻止对重要字段的意外或越权更新，必须用 BEFORE UPDATE 触发器配合 SIGNAL 主动中止操作。AFTER UPDATE 已经写入磁盘，无法回滚本行变更，只能补救，不能“防止”。

常见错误现象是写了 AFTER UPDATE 然后在其中 UPDATE 同表，结果报错 Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger —— MySQL 明确禁止同表递归写入。

• 只允许在 BEFORE UPDATE 中检查 OLD.column 和 NEW.column 的差异
• 若发现不被允许的修改（如 status 从 'shipped' 改为 'pending'），立即 SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Status cannot be reverted'
• 避免在条件判断中使用子查询或函数调用，否则可能因执行计划不稳定导致误判

如何精准识别“重要数据”的修改意图

不能只看字段值是否变化，得结合业务语义。比如 price 字段允许调高但禁止调低，created_at 字段根本不能被任何 UPDATE 修改。

典型场景包括：财务单据状态不可逆、用户账户冻结标记不可解除、主键关联字段（如 user_id）被篡改、敏感字段（如 salary）被非HR角色更新。

• 用 IF OLD.status != NEW.status AND NEW.status = 'draft' THEN ... 判断特定状态回退
• 用 IF NEW.created_at != OLD.created_at THEN SIGNAL ... 封禁时间戳篡改
• 若需校验操作者权限，触发器本身无法获取应用层用户身份，必须依赖已写入的字段（如 updated_by_role）或提前在应用层注入上下文

触发器里访问其他表做校验的风险与替代方案

想在触发器里查 roles 表确认当前操作人是否有权修改，看起来合理，但实际会引入严重隐患：锁等待、死锁、性能抖动，且 MySQL 8.0.16+ 对跨表查询在触发器中的支持仍受限。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

更糟的是，如果校验逻辑涉及大表 JOIN 或未命中索引，一次 UPDATE 可能卡住整个表的 DML 流量。

• 优先把权限信息冗余进当前表（如加 last_updated_by_role 字段），在触发器中直接比对
• 若必须查外部表，确保只走主键或唯一索引，并加上 SELECT ... FOR SHARE 避免升级为排他锁
• 绝对不要在触发器中执行 INSERT INTO audit_log 这类写操作——它可能和主事务形成锁竞争，尤其在高并发更新时

为什么有些 UPDATE 看似被拦截了，却没报错

最常被忽略的一点：MySQL 在遇到 SIGNAL 时抛出异常，但如果你的应用用了自动重试机制（比如某些 ORM 或连接池配置了 retry-on-failure），它可能默默重试并成功——而你只看到日志里一条失败记录，误以为拦截生效了。

另一个隐蔽坑是：触发器中用了 IF ... THEN ... END IF; 但漏写 ELSE 分支，导致部分非法路径没走到 SIGNAL，表面安静实则放行。

• 所有校验分支必须显式覆盖，不要依赖“默认不处理即安全”
• 上线前用 SHOW WARNINGS 配合真实 UPDATE 语句验证是否真抛出了 SQLSTATE '45000'
• 触发器逻辑越短越好，复杂校验应下沉到应用层或用存储过程封装，数据库层只做原子级断言