触发器应写在业务表（如orders、returns、user_checkins）上，而非结果表user_points；必须用after时机确保事务一致性；更新积分宜用insert ... on duplicate key update避免锁表。
触发器该写在哪个表上才合理
积分变动必须和业务动作强绑定，比如用户下单、退货、签到。不能把触发器挂在 user_points 表上——它只是结果表，没有业务上下文。真正该监听的是业务表：订单表 orders、退货表 returns、签到记录表 user_checkins。
常见错误是把所有积分逻辑塞进一个触发器里判断类型字段，结果一加字段就改触发器，维护成本飙升。更稳妥的做法是：每个业务表配一个专用触发器，职责单一，出问题也容易定位。
-
orders表的AFTER INSERT触发器负责加积分（按金额或固定值） -
returns表的AFTER INSERT触发器负责扣积分（还原订单所赠积分） -
user_checkins表的AFTER INSERT触发器负责每日签到加固定分
INSERT/UPDATE/DELETE 选哪个时机
积分变动必须等业务数据落库成功后再执行，否则会出现「订单已创建但积分没加」这种不一致。所以一律用 AFTER 类型，绝不用 BEFORE。
特别注意：更新订单状态（如从「待支付」变「已完成」）这类操作，要用 AFTER UPDATE，且必须检查 OLD.status != 'completed' AND NEW.status = 'completed'，避免重复加积分。MySQL 的 NEW 和 OLD 变量只在行级触发器中可用，语句级触发器无法获取具体行数据。
- 新增订单 →
AFTER INSERT - 修改订单状态 →
AFTER UPDATE，带条件判断 - 删除退货记录（极少发生）→
AFTER DELETE，慎用，通常退货是插入新记录而非删原单
怎么安全地更新积分表而不锁表
直接在触发器里执行 UPDATE user_points SET points = points + 10 WHERE user_id = NEW.user_id 看似简单，但高并发下容易引发死锁或间隙锁阻塞。尤其当多个触发器同时更新同一用户积分时，数据库会串行化执行。
更可靠的做法是用 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO（取决于 MySQL 版本），前提是 user_points 表主键或唯一索引包含 user_id。这样能规避 SELECT + UPDATE 的两步操作，减少锁持有时间。
示例（MySQL）：
INSERT INTO user_points (user_id, points) VALUES (NEW.user_id, 10) ON DUPLICATE KEY UPDATE points = points + 10;
- 确保
user_points.user_id是主键或有唯一约束 - 避免在触发器里调用存储过程或外部函数，增加不可控延迟
- 不要在触发器里做跨库操作，MySQL 不支持跨库触发器事务一致性
为什么不能在触发器里写日志或发消息
触发器本质是事务的一部分，里面任何失败都会导致整个事务回滚。如果在里面调用 HTTP 接口发通知、写文件日志、甚至插入另一张日志表（没设好事务隔离级别），轻则拖慢主业务，重则让下单失败——用户明明看到「支付成功」，实际订单根本没生成。
正确做法是：触发器只做最简幂等更新；日志、通知、风控校验等后续动作，通过监听 binlog 或业务表变更事件异步处理（比如用 Canal、Debezium 或定时扫描增量表）。
- 触发器内禁止
INSERT INTO audit_log（除非该表引擎为BLACKHOLE或明确接受丢失） - 禁止
CALL notify_service()存储过程 - 禁止
SELECT ... FOR UPDATE查询其他行，极易引发锁等待
复杂积分规则（比如“连续签到第7天额外加50分”）也不适合放触发器里实现，状态机逻辑应交给应用层或独立积分服务。触发器只管原子、确定、无副作用的增减。
