MySQL触发器禁止直接读写同表，应改用AFTER触发器写日志表、将等级计算移至应用层或用存储过程封装；自定义函数需声明DETERMINISTIC。
触发器里不能直接读写同一张表
在 users 表上建 BEFORE UPDATE 触发器，想根据积分变化更新同表的 level 字段？会报错 ERROR 1442: Can't update table 'users' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。MySQL 禁止在触发器中对触发它的表做 DML 操作。
实操建议：
- 改用
AFTER UPDATE触发器，但只能做日志、通知或更新其他表（如user_levels_history），不能回写原表 - 把等级计算逻辑移到应用层，在更新积分前就算好新等级，一次完成
UPDATE users SET score = ?, level = ? WHERE id = ? - 若必须数据库内闭环，可改用存储过程封装积分+等级联动更新，并显式调用，避开触发器限制
用 AFTER INSERT/UPDATE 触发器写入历史表更安全
同步变动本身没问题，关键是“同步到哪”。直接改原表不行，但记录变更、驱动下游服务是触发器的典型用途。
常见错误现象：在 BEFORE INSERT 中试图插入一条 user_level_log 记录，却发现事务未提交时日志已落库，导致主表回滚但日志残留。
实操建议：
- 统一用
AFTER INSERT或AFTER UPDATE触发器写日志表，确保主表变更已成功 - 日志表字段至少包含：
user_id、old_score、new_score、old_level、new_level、updated_at - 示例触发器逻辑：
CREATE TRIGGER tr_user_score_update AFTER UPDATE ON users<br>FOR EACH ROW<br>BEGIN<br> IF OLD.score != NEW.score THEN<br> INSERT INTO user_level_log (user_id, old_score, new_score, old_level, new_level)<br> VALUES (NEW.id, OLD.score, NEW.score, OLD.level, get_level_by_score(NEW.score));<br> END IF;<br>END;
等级计算函数必须是 deterministic 的
如果触发器里调用自定义函数（如 get_level_by_score()）来算新等级，MySQL 要求该函数声明为 DETERMINISTIC，否则建触发器会失败：ERROR 1418: This function has none of DETERMINISTIC...
使用场景：积分到等级映射通常是静态规则（比如每 1000 分升一级），适合封装成函数复用。
实操建议：
- 创建函数时显式加
DETERMINISTIC属性：CREATE FUNCTION get_level_by_score(s INT) RETURNS INT<br>DETERMINISTIC<br>BEGIN<br> RETURN FLOOR(s / 1000) + 1;<br>END;
- 避免在函数里查表或调用非确定性函数（如
NOW()、RAND()） - 若等级规则复杂（依赖活动状态、黑名单等），别硬塞进触发器——这类逻辑应由应用控制，触发器只负责轻量、确定性同步
触发器无法捕获批量 UPDATE 的中间状态
执行 UPDATE users SET score = score + 50 WHERE status = 'active' 时，触发器对每一行生效一次，但你拿不到“本次批量操作共影响多少用户”或“总积分变动量”这类聚合信息。
性能影响：如果触发器里有 INSERT 或远程调用，批量更新可能意外放大开销，甚至拖慢主 SQL 执行。
实操建议：
- 触发器体内部避免循环、子查询、外部 API 调用；只做简单字段提取和单行 INSERT
- 需要聚合统计？用定时任务扫描
user_level_log表，或让应用在批量操作后主动补一条汇总日志 - 监控触发器执行耗时：开启
slow_query_log并设置long_query_time = 0，观察是否因触发器导致慢查突增
