触发器必须建在实际产生积分行为的源头表上，如订单支付建在orders表、充值退款建在transactions表；建错表会导致漏触发或重复计算，应依据业务规则中“什么操作直接导致积分变化”来确定源头表，并优先选用AFTER INSERT。
触发器该建在订单表还是交易流水表
必须建在实际产生积分行为的源头表上。比如用户下单支付后才计分，就建在 orders 表；如果是每笔充值、退款都影响积分，则建在 transactions 表。建错表会导致漏触发或重复计算——比如在用户表上监听 UPDATE，改个昵称就扣积分，显然不合理。
常见错误现象：INSERT INTO orders 执行了，但积分没加；查日志发现触发器绑在 users 表，根本没被调用。
- 判断依据：看业务规则里“什么操作”直接导致积分变化，那个表就是源头
- 优先选
AFTER INSERT而非BEFORE，避免因主键未生成或外键约束失败导致触发器中断 - 若涉及多表关联（如订单要查商品类型决定积分倍率），确保触发器内用
JOIN或子查询能安全访问相关数据，别依赖事务未提交的临时状态
INSERT 触发器里怎么安全更新用户积分
不能直接写 UPDATE users SET points = points + 100 WHERE id = NEW.user_id 就完事。并发下单时两个触发器同时读到旧值、同时+100，结果只加了一次。
正确做法是用原子更新：
UPDATE users
SET points = points + (SELECT COALESCE(SUM(rule.points), 0)
FROM points_rules rule
WHERE rule.product_type = NEW.product_type)
WHERE id = NEW.user_id;关键点：
- 把积分计算逻辑尽量收进
SELECT子句，避免先查再更新的两步操作 - 务必用
COALESCE防止规则未匹配导致NULL传播，进而使整个points变成NULL - 如果积分规则复杂（比如满减、时段加成），建议把计算封装成函数，如
calculate_points(NEW.order_id)，但要注意函数内不能修改数据，否则触发器报错
如何处理退款/取消订单导致的积分回退
只写 INSERT 触发器不够。订单状态变成 'cancelled' 或 'refunded' 时，必须反向扣减之前加的积分。这时得用 UPDATE 触发器监听状态字段变化。
示例条件判断：
IF OLD.status != 'paid' AND NEW.status = 'paid' THEN
-- 加分
ELSIF OLD.status = 'paid' AND NEW.status IN ('cancelled', 'refunded') THEN
-- 扣分（取负值）
END IF;容易踩的坑：
- 别只比对
NEW.status，必须用OLD.status != NEW.status判断是否真发生了变更，否则每次更新备注字段都触发积分变动 - 扣分时不能简单
points = points - X，要防止扣成负数——加LEAST(points, X)或在应用层校验，数据库层用GREATEST(points - X, 0) - 如果原订单积分是动态算的（比如含优惠券折扣），回退时得重新查原始规则，不能只存一个固定数值
触发器报错导致事务失败怎么办
MySQL 默认下，触发器里任何 SQL 报错（比如除零、外键不存在、子查询返回多行）都会让整个 INSERT/UPDATE 回滚。这看似安全，但可能让本该成功的订单卡住。
缓解方式有限，但必须做：
- 所有子查询必须加
LIMIT 1或用聚合函数兜底，杜绝“Subquery returns more than 1 row” - 用
DECLARE EXIT HANDLER FOR SQLEXCEPTION捕获异常，记录到日志表（如trigger_error_log），然后RESIGNAL或静默忽略——后者仅适用于非关键路径，比如赠送积分失败不影响主交易 - 上线前用
SHOW CREATE TRIGGER trigger_name确认定义无语法错误，且权限足够访问所涉所有表
真正麻烦的是跨库或调用外部服务的场景——触发器不支持 HTTP 请求，这类逻辑必须移出数据库，改由应用层在事务提交后异步补发积分事件。
