必须建在consumption_records表上且为AFTER INSERT触发器，因消费行为是唯一可靠触发时机，仅此可访问NEW.amount；用户表是被修改方，不应主动触发自身更新。
触发器该建在消费表还是用户表
必须建在 consumption_records 表上，且类型为 AFTER INSERT。用户表是被修改方，不能也不应该主动触发自身更新；真正发生业务动作的是新插入一条消费记录，这是唯一可靠、无歧义的触发时机。
常见错误是试图在用户表上建 BEFORE UPDATE 触发器来“响应消费”，这会导致逻辑断裂：消费行为和积分更新之间没有直接关联路径，也无法获取本次消费金额。
- 触发器必须能访问刚插入的行，
NEW.amount只在INSERT触发器中可用 - 若用
UPDATE触发器监听消费表状态变更（如 status=‘paid’），需额外处理幂等性，增加复杂度 - MySQL 8.0+ 支持多表触发器，但标准做法仍是单表 + 简洁逻辑
UPDATE 用户表时如何避免主键冲突或空值报错
核心是用 UPDATE ... JOIN 或子查询确保只更新真实存在的用户，并跳过无效 user_id。直接写 UPDATE users SET points = points + NEW.amount WHERE id = NEW.user_id 在 NEW.user_id 为空或不存在时会静默失败（MySQL 默认不报错），或产生意外的全表更新（如果 WHERE 条件失效）。
安全写法必须显式校验：
UPDATE users u JOIN consumption_records c ON u.id = c.user_id SET u.points = u.points + c.amount WHERE c.id = NEW.id;
- 用
JOIN替代WHERE u.id = NEW.user_id，天然过滤掉user_id不存在的情况 - 条件锁定到
c.id = NEW.id，确保只影响本次插入的那条记录对应的用户 - 如果
consumption_records.user_id允许为 NULL，需在触发器开头加IF NEW.user_id IS NULL THEN LEAVE proc_label; END IF;
触发器里能不能调用存储过程或事务控制
可以调用存储过程，但不能在触发器内显式使用 BEGIN...END TRANSACTION。MySQL 触发器自动运行在当前语句的事务上下文中，嵌套事务会报错 ERROR 1305 (42000): SAVEPOINT does not exist 或直接拒绝执行。
这意味着：积分更新和消费记录插入必然原子性成功或失败，无需、也不能手动加事务——这是优势也是限制。
- 若需复杂逻辑（如积分上限检查、等级变更通知），封装进存储过程再从触发器调用，例如
CALL update_user_points(NEW.user_id, NEW.amount); - 避免在触发器中执行耗时操作（如远程 API 调用、大表统计），会拖慢主业务 SQL 响应
- MySQL 5.7+ 对触发器内游标、循环支持有限，简单
UPDATE+IF判断足够覆盖 95% 场景
为什么上线后积分偶尔没加，但消费记录存在
最常见原因是触发器未启用，或创建时用了错误的分隔符导致实际未生效。MySQL 的 SHOW TRIGGERS 不报错不代表触发器真在工作——它只显示元数据，不验证逻辑正确性。
排查顺序必须是：
- 执行
SHOW TRIGGERS LIKE 'consumption_records';确认状态列为ENABLED - 查 MySQL 错误日志，搜索关键词
trigger或具体触发器名，常有语法错误被静默忽略 - 手动模拟插入：
INSERT INTO consumption_records (user_id, amount) VALUES (123, 50);，再查users表对应记录，不要依赖应用层日志 - 注意字符集问题：如果
consumption_records和users表字符集不一致（如 utf8mb4 vs utf8），JOIN可能因隐式转换失败而跳过更新
触发器逻辑本身很轻量，但一旦出问题往往难以定位——它不走常规调用链路，也没有返回值，只能靠日志和直接验证。
