核心是用before update/insert触发器比对new与old值校验变动范围，after无法阻止非法写入；需处理null、浮点精度及并发边界场景。
触发器里怎么判断数值变动是否超限
核心是用 NEW 和 OLD 引用新旧值，在 BEFORE UPDATE 或 BEFORE INSERT 里做校验。不能等数据写进表再查，否则约束失效。
常见错误是写成 AFTER 触发器——那时数据已落库，ROLLBACK 也晚了；还有人漏掉 INSERT 场景，只拦 UPDATE，导致初始值就能越界。
- 变动范围必须明确：比如字段
score只允许在[0, 100]之间，且每次变更幅度不能超过 ±5 - 对
INSERT，只比对NEW.score是否在全局范围内；对UPDATE，还要算ABS(NEW.score - OLD.score) - MySQL 中用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'score change too large';中断操作；PostgreSQL 用RAISE EXCEPTION
MySQL 和 PostgreSQL 的语法差异在哪
MySQL 用 DELIMITER 切换语句结束符，PostgreSQL 直接用 $$ 定界符，但两者都要求触发器体里显式声明变量（如 DECLARE delta DECIMAL(5,2);）。
容易踩的坑是 PostgreSQL 对 NULL 更敏感：如果旧值为 NULL（比如首次更新空字段），OLD.score 是 NULL，直接参与减法会得 NULL，导致条件判断失效。
- MySQL 示例片段：
IF NEW.score 100 THEN<br> SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'score out of range';<br>END IF;<br>IF TG_OP = 'UPDATE' THEN<br> SET delta = ABS(NEW.score - OLD.score);<br> IF delta > 5 THEN<br> SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'score change exceeds 5';<br> END IF;<br>END IF;
- PostgreSQL 要加
COALESCE(OLD.score, NEW.score)避免NULL参与运算，否则ABS(NEW.score - OLD.score)永远为NULL，不触发报错
为什么不能只靠 CHECK 约束解决这个问题
CHECK 约束只能限制单行单字段的静态取值，没法表达“相对于旧值的变化量”这种动态逻辑。比如你设 CHECK (score BETWEEN 0 AND 100)，它拦不住从 98 更新到 103——因为 103 本身合法，但它超出了允许的 ±5 变动范围。
另一个盲区是跨行依赖：如果业务规则是“同一用户两次修改间隔不得小于 1 小时”，那必须查历史记录，而 CHECK 连 SELECT 都不允许执行。
-
CHECK在 PostgreSQL 12+ 支持函数调用，但 MySQL 直到 8.0.16 才支持，且仍不支持子查询 - 触发器能访问
OLD/NEW，也能执行任意SELECT查其他行，但代价是性能开销和调试难度上升 - 高并发下要注意：触发器内查表可能引发锁等待，尤其用
SELECT ... FOR UPDATE时
上线前必须验证的三个边界场景
真实业务里最容易出问题的不是常规流程，而是边界值、空值、并发写入。光测 “95→100” 不够，得专门构造这些 case。
- 插入
NULL后第一次更新：比如字段允许NULL，首次设为 10，这时OLD.score是NULL，计算差值前没处理就会跳过校验 - 浮点字段精度溢出：
DECIMAL(5,2)存 99.99，想 +0.02 → 100.01，表面看超限，但实际存储可能四舍五入成 100.00，触发器里用NEW.score值判断才准 - 并发更新同一行：两个事务同时读到旧值 50，各自算出新值 54 和 55，都满足 ±5，但最终结果可能是 55，而 50→55 本身合法；但如果规则是“两次更新不能重叠”，就得加额外锁或时间戳校验
触发器逻辑看着简单，但数值变动范围这类规则往往隐含状态依赖，真正难的是把“变化”这个动作本身变成可验证、可复现、可审计的数据行为。
