应在 BEFORE UPDATE 触发器中用 IF NEW.price != OLD.price THEN 判断价格变更，若 NEW.price < 0 则 SIGNAL SQLSTATE '45000' 报错中断，错误信息需包含具体 product ID；禁止在触发器内 SET NEW.price = 0 或调用函数校验，且须绑定至商品主表。
触发器里怎么判断并拒绝负价格更新
直接在 BEFORE UPDATE 触发器中检查 NEW.price，如果小于 0 就用 SIGNAL SQLSTATE '45000' 抛出错误中断执行。MySQL 不允许在触发器里用 ROLLBACK，所以必须靠 SIGNAL 阻断。
- 只对
price字段变化敏感：建议加条件IF NEW.price != OLD.price THEN，避免无意义检查 - 错误码选
'45000'是通用未定义异常，应用层容易捕获；别用'HY000'这类模糊码 - 错误信息要具体，比如
"Price cannot be negative for product ID: " + CAST(NEW.id AS CHAR)，方便排查是哪条记录触发的
触发器绑定到哪个表和时机才有效
必须建在商品主表（比如 products）上，且类型为 BEFORE UPDATE。建在 AFTER UPDATE 里毫无意义——改都改完了，再拦也晚了。
- 如果表有多个更新入口（比如应用直连、ETL脚本、其他触发器），这个触发器对所有路径都生效
- 注意字段名大小写：MySQL 默认不区分大小写，但若表启用了
lower_case_table_names=0，且字段定义为Price，就得写成NEW.Price - 不要在触发器里调用存储过程或函数来校验——可能引发递归或权限问题，简单逻辑就地写死更稳
为什么不能用 UPDATE 语句覆盖值来“修正”负数
有人想在触发器里写 SET NEW.price = 0 替代报错，这看似温和，实则埋雷：业务逻辑被静默篡改，下游系统可能拿到非预期值，且无法追溯谁、何时、为何被重置。
- 前端/应用层看到的是“修改成功”，但实际价格没按请求存入，监控和日志对不上
- 审计要求明确拒绝非法输入，而不是悄悄兜底；合规场景下这种“自动修正”可能违反数据完整性策略
- 如果真需要默认值，应在应用层或
DEFAULT约束里定义，而非在触发器里做隐式赋值
测试时容易漏掉的边界情况
光测 UPDATE products SET price = -1 WHERE id = 123 不够，还得覆盖浮点、NULL、空字符串等干扰项。
-
NEW.price为NULL时，NEW.price 返回 <code>UNKNOWN而非FALSE，需显式写成NEW.price IS NOT NULL AND NEW.price - 如果 price 是
DECIMAL(10,2)，传入'-0.00'字符串会被转成0.00，不会触发拦截；但'-0.01'会 - 批量更新如
UPDATE products SET price = price * -1会逐行触发，每行都走一遍判断，性能影响小，但日志会刷屏
真正麻烦的是触发器嵌套：如果另一个触发器或外键级联操作间接更新了 price，这个校验依然生效，但堆栈深了 debug 起来得翻 error log 里的完整 call stack。
