BEFORE UPDATE触发器无法真正防篡改，仅能校验数据合法性（如字段值范围、状态迁移规则），无法判断操作者权限或业务上下文；真正的防篡改需应用层鉴权、审计日志与行级权限协同。
不能靠 BEFORE UPDATE 触发器“防篡改”——它只能拦住非法修改，拦不住合法但恶意的修改。 真正的防篡改需要应用层鉴权 + 审计日志 + 行级权限控制，触发器顶多是最后一道校验闸门，且极易被绕过。
BEFORE UPDATE 里 SIGNAL 能拦什么
它只对明确违反预设规则的 UPDATE 语句生效，比如字段值越界、格式错误、业务逻辑冲突。只要 SQL 语句本身合法（语法正确、权限够、没违反外键/唯一约束），触发器就无权拒绝。
- 能拦：
UPDATE users SET status = 'deleted' WHERE id = 123（若触发器规定 status 只能是 'active'/'inactive'） - 拦不住：
UPDATE users SET name = 'hacker' WHERE id = 123 AND created_by = 'admin'（条件合法，触发器看不到上下文权限） - 更拦不住：直接连库用 root 执行 update，或通过应用后门接口提交合法请求
SIGNAL 报错必须用 BEFORE，不能写 AFTER
AFTER UPDATE 触发器中写 SIGNAL 会报错或无效——因为数据已经落库，MySQL 不允许在 AFTER 阶段中断已成功的语句。只有 BEFORE UPDATE 才有“拦截权”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
BEFORE中SIGNAL会让整个语句回滚，NEW和OLD都可读写 - 错误码统一用
SQLSTATE '45000'，避免和系统错误混淆 - 不要在
SIGNAL前做耗时计算（如子查询、函数调用），否则拖慢所有更新
常见误用：把权限判断塞进触发器
比如想在触发器里查当前用户是否属于某个角色，再决定放不放行——这不可靠。
-
CURRENT_USER()或USER()在连接池复用场景下可能返回代理用户，不是真实操作人 - 触发器无法获取 HTTP header、JWT payload、session ID 等应用层上下文
- 一旦依赖这类信息，就等于把权限逻辑下沉到 DB 层，违背分层原则，也难以审计
- 真要限制字段修改权（如禁止非财务人员改
salary），应在应用层拦截，或用 MySQL 8.0+ 的ROLE+ 列权限（GRANT UPDATE(salary) ON ... TO ...）
真正该用 SIGNAL 校验的场景
聚焦在“数据自身合法性”，而非“谁改的”或“为什么改”。
- 业务规则硬约束：如
price > 0、end_time > start_time - 状态迁移合规性：如订单从
'shipped'不能直接跳到'cancelled'，中间必须经过'delivered' - 敏感字段变更留痕前提：如改
email必须同时提供email_verified = 1，否则SIGNAL - 示例片段：
IF NEW.email != OLD.email AND NEW.email_verified != 1 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '邮箱变更需先验证'; END IF;
触发器里的 SIGNAL 是把双刃剑：它让校验变得“数据库级强制”，但也让调试变困难、性能变敏感、死锁风险上升。最常被忽略的一点是——它完全不防 prepared statement 绕过、不防批量 update 中的部分成功、也不防应用层伪造 NEW 值（比如用存储过程包装 update）。真要防篡改，得从连接认证、查询路由、变更审计链路整体设计，而不是指望一个 BEFORE UPDATE。
