必须用 BEFORE UPDATE 触发器 + SIGNAL 报错才能阻止非法更新；AFTER UPDATE 无法拦截，因数据已写入磁盘；BEFORE 阶段可读 OLD 和 NEW 值进行校验。
直接结论：必须用 BEFORE UPDATE 触发器 + SIGNAL SQLSTATE '45000' 报错，才能真正阻止非法更新；AFTER UPDATE 什么都拦不住，数据早进库了。
为什么只能用 BEFORE UPDATE？
MySQL 的 AFTER UPDATE 在语句执行完才触发，此时 NEW.balance 已写入磁盘，报错也救不回来。而 BEFORE UPDATE 是在写入前最后一刻校验，能中断整个操作。
-
BEFORE阶段可安全读OLD.column和NEW.column，做差值、范围、状态跳转等判断 IF NEW.amount 这类逻辑必须放这里- 别试图在
BEFORE里“自动修正”值（比如SET NEW.amount = ABS(NEW.amount)），掩盖问题比报错更危险
校验哪些内容才算真正防住非法更新？
不是所有字段都值得校验，重点盯三类高危变更：
-
不可变字段：如
id、created_at、invoice_no，用NEW.id != OLD.id判断是否被改 -
状态机越界：如
OLD.status = 'paid'时，NEW.status只能是'refunded'或'reversed'，其他一律SIGNAL -
数值合理性：余额变动超阈值、金额小数位超标（需用
CAST(NEW.amount AS CHAR)转字符串再算小数点后位数）
容易踩的坑有哪些？
这些细节不注意，触发器就形同虚设：
-
CURRENT_USER()不是操作人，是数据库连接账号（如app@10.0.2.5）；真要记录谁改的，应用层得先执行SET @current_app_user = 'u12345'; - NULL 比较要用
IS DISTINCT FROM（MySQL 8.0.22+）或手动写(NEW.field IS NULL) != (OLD.field IS NULL) OR NEW.field != OLD.field - 触发器里禁止查其他表、调存储函数——会拖慢所有
UPDATE，且可能引发死锁或权限错误 - 批量
INSERT或LOAD DATA INFILE会让触发器逐行执行，性能断崖式下跌，上线前必须压测
真正难的不是写几行 SIGNAL，而是确保所有写入口（运维脚本、旧服务、ETL 工具）都绕不开这个触发器——只要有一个直连账号有 UPDATE 权限，防护就失效。
