应使用BEFORE UPDATE触发器直接赋值NEW.discount，避免AFTER中UPDATE引发递归报错；折扣计算需基于确定性表达式、单行子查询、COALESCE处理NULL，并用ROUND保证精度；多字段联动时扩展判断条件；并发场景下触发器仅适合“尽力而为”填充，强一致应交由应用层或视图处理。
触发器里改价格字段会引发递归更新
直接在 UPDATE 触发器里更新同一张表的 discount 字段，极大概率触发自身再次执行——尤其当触发器定义为 AFTER UPDATE 且语句又修改了触发条件涉及的列时。MySQL 默认禁止这种递归，会报错 Can't update table 'orders' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。
解决思路是避开“自己改自己”：用 BEFORE UPDATE，在数据写入前就计算好新折扣值并赋给 NEW.discount，不执行额外 UPDATE 语句。
- 只在
BEFORE UPDATE中操作NEW.*，不碰UPDATE ... SET - 确保触发条件只检查
OLD.price != NEW.price，避免其他字段变动误触发 - 若折扣逻辑依赖其他表（如客户等级表），需用
SELECT ... INTO查询，但注意不能调用含UPDATE的存储函数
折扣重算逻辑必须用确定性表达式
触发器里不能调用非确定性函数（如 NOW()、RAND()），否则 MySQL 可能拒绝创建或主从同步出错。折扣计算得基于当前行数据和关联查询结果，且每次输入相同，输出必须一致。
例如：按客户等级查折扣率，再乘以新价格：
SELECT rate INTO discount_rate FROM customer_tiers WHERE id = NEW.customer_id;
然后：SET NEW.discount = ROUND(NEW.price * discount_rate, 2);
- 所有子查询必须返回单行单值，否则触发器运行时报错
Subquery returns more than 1 row - 用
ROUND(..., 2)避免浮点精度问题导致前端显示异常 - 如果客户等级不存在，
discount_rate为NULL，会导致整个discount变成NULL，建议加默认值：COALESCE(discount_rate, 0)
多字段联动时要小心触发时机和范围
实际业务中，价格变更常伴随数量、税率、促销标识等一起改。若只监控 price，而用户同时改了 quantity 和 price，折扣却只按新价格算，可能漏掉数量影响（比如满件折）。
这时应把判断条件扩展为：
IF OLD.price != NEW.price OR OLD.quantity != NEW.quantity OR OLD.is_promo != NEW.is_promo THEN
- 别用
OLD.* IS DISTINCT FROM NEW.*（PostgreSQL 语法，MySQL 不支持） - 对可能为
NULL的字段，用IS NULL显式判断，例如：(OLD.promo_code IS NULL) != (NEW.promo_code IS NULL) OR OLD.promo_code != NEW.promo_code - 复杂逻辑建议封装进存储函数，但该函数只能含
SELECT和计算，不能含UPDATE/INSERT
测试时容易忽略并发修改风险
触发器本身不解决并发问题。两个事务同时更新同一行价格，各自读到旧折扣率、各自重算、各自写入，最终结果可能是错误的（丢失一次折扣调整）。这不是触发器写得不对，而是业务层没加锁或版本控制。
简单应对方式是在应用层加 SELECT ... FOR UPDATE，或在触发器里用 GET_LOCK() 做轻量级行级协调（仅限开发环境验证，生产慎用）。
真正需要强一致的场景，折扣字段不该由触发器维护，而应改为视图计算或应用层统一结算——触发器适合做“尽力而为”的自动填充，不是强事务保障机制。
