MySQL触发器无法可靠实现积分防篡改校验，因其可被绕过、无法验证操作来源与业务上下文，且存在权限、日志一致性及逻辑局限等根本缺陷。
直接说结论：MySQL触发器无法可靠实现积分防篡改校验，因为触发器本身可被绕过，且无法验证操作来源或业务逻辑上下文。
为什么 BEFORE UPDATE 触发器拦不住恶意修改
很多人以为在 users 表上加个 BEFORE UPDATE 触发器、比对新旧积分值就能防篡改，但实际漏洞明显：
- 触发器只响应
UPDATE语句，不拦截INSERT（如通过备份还原插入伪造记录）或直接修改磁盘文件（DBA权限下） - 用户可能通过应用层绕过业务接口，直连数据库执行
UPDATE users SET score = 999999 WHERE id = 123—— 触发器会运行，但你没法判断这是否是合法的运营补分操作 - 触发器内部无法获取 SQL 执行来源（比如 HTTP 请求 ID、用户 session、调用栈），也就无法关联到具体业务动作
- 若触发器里写
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'score tampering detected'，错误信息会暴露校验逻辑，反而帮攻击者逆向规则
真正该校验的地方：应用层 + 审计日志 + 变更溯源
积分变更必须由业务服务统一入口处理，数据库只做最终持久化。防篡改的关键不在“拦”，而在“证”和“溯”：
- 每次积分变更必须携带不可伪造的
trace_id和reason_code（如"order_refund_2024"），存入score_logs表，且该表仅允许INSERT（禁止UPDATE/DELETE） - 应用层计算变更前后的合法性：比如退款返积分，必须核对原订单状态、退款金额、积分返还比例，这些逻辑无法下推到触发器
- 数据库开启
general_log或使用mysqlbinlog解析 binlog，配合时间戳、账号、SQL 原文做离线审计 —— 触发器日志无法替代这个 - 敏感操作（如后台强制调分）必须走审批流，审批通过后生成带签名的 token，应用层验证 token 有效性才执行 DB 更新
如果非要用触发器，只能做基础兜底（且要避开常见坑）
仅建议在开发/测试环境用触发器做简单一致性提醒，生产环境慎用。注意这些硬性限制：
- MySQL 5.7+ 才支持
SIGNAL；8.0 之前无法在触发器中调用存储函数访问其他表（会报ERROR 1442），所以不能查score_logs做历史比对 - 不要在触发器里写
INSERT INTO audit_table—— 若事务回滚，审计记录不会回滚，导致日志与数据不一致 - 若坚持记录，用
INSERT DELAYED（已弃用）或改用外部消息队列（如 Kafka）异步投递，避免拖慢主事务 - 示例（仅作示意，勿直接上线）：
DELIMITER $$<br>CREATE TRIGGER check_score_change<br>BEFORE UPDATE ON users<br>FOR EACH ROW<br>BEGIN<br> IF NEW.score < OLD.score AND ABS(NEW.score - OLD.score) > 10000 THEN<br> SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'large score deduction without approval';<br> END IF;<br>END$$<br>DELIMITER ;
最易被忽略的一点：哪怕你把触发器、日志、签名全加上，只要应用服务的数据库账号有 UPDATE 权限，它被攻破就等于积分系统被攻破。防篡改的本质是权限收敛 + 操作留痕 + 业务逻辑闭环，不是靠一个触发器站岗。
