触发器不能实现评分，仅能响应数据变更并触发校验或辅助计算；真实评分须由外部系统或SQL表达式完成，触发器只充当“开关”，负责在INSERT/UPDATE时调用或拦截评分动作。
触发器不能直接“实现评分”，它只能响应数据变更、执行校验或辅助计算；真正的评分逻辑必须由外部系统或SQL表达式完成，触发器只负责在INSERT/UPDATE时调用或拦截。
触发器不是评分引擎，而是评分动作的“开关”
很多人误以为在CREATE TRIGGER里写个SELECT AVG(score)就能自动打分——不行。触发器本身不返回结果集，也不能直接更新其他表的聚合字段（除非显式UPDATE）。它的作用是：当某行成绩被插入或修改时，检查合法性、记录日志、或触发下游评分计算（比如写入待处理队列）。
- 触发器内不能使用
SELECT ... INTO或RETURN向应用返回评分值 - 若需实时更新课程平均分，必须在触发器中显式
UPDATE courses SET avg_score = ...，且要处理多行inserted带来的聚合逻辑 - 避免在触发器里调用耗时操作（如远程API、复杂模型预测），否则会阻塞DML事务
用AFTER INSERT/UPDATE触发器维护加权平均分
假设你有一张ratings表，含course_id、score、votes（权重），想在每次新增评分后自动刷新courses表中的weighted_avg字段。关键点是：必须对inserted中涉及的每个course_id重新计算全量加权平均，而非只算新行贡献。
- 错误做法：
UPDATE courses SET weighted_avg = (new_score * new_votes) / new_votes—— 忽略历史数据 - 正确做法：在触发器中对每个
course_id执行SELECT COALESCE(SUM(score * votes) * 1.0 / NULLIF(SUM(votes), 0), 0) FROM ratings WHERE course_id = @cid - 必须用
GROUP BY course_id配合游标或CTE遍历inserted里的所有课程ID，否则漏更新 - 注意
NULLIF(SUM(votes), 0)防除零，* 1.0防整数截断（尤其SQL Server）
触发器 + 临时表 + 批量聚合，避免逐行更新性能陷阱
高频写入场景下，对每一行INSERT都跑一次全表SUM()会严重拖慢性能。更合理的做法是：把变更暂存到临时表，再统一聚合更新。
- 在
AFTER INSERT触发器中，先SELECT course_id INTO #tmp_updated FROM inserted - 然后
UPDATE c SET weighted_avg = r.wavg FROM courses c INNER JOIN (SELECT course_id, COALESCE(SUM(score * votes) * 1.0 / NULLIF(SUM(votes), 0), 0) wavg FROM ratings r INNER JOIN #tmp_updated t ON r.course_id = t.course_id GROUP BY course_id) r ON c.id = r.course_id - 这样把N次单行扫描变成1次关联聚合，吞吐量提升明显
- 别忘了
DROP TABLE #tmp_updated或用DECLARE @t TABLE替代，避免锁表
真正需要模型评分时，触发器只做“投递”，别硬扛
如果你的评分依赖机器学习模型（比如用sp_rxPredict预测用户信用分），触发器绝不能直接调用它——sp_rxPredict是存储过程，执行需权限、耗资源，且无法在触发器上下文中稳定运行。
- 安全做法：触发器只向消息表（如
pending_scores）插入记录，由外部作业轮询处理 - 或用
service broker发消息，解耦评分与事务 - 强行在触发器里调
EXEC sp_rxPredict会导致事务超时、权限失败（因触发器默认无UNSAFE ASSEMBLY权限） - 哪怕成功，也会让
INSERT响应时间从毫秒级变成秒级，业务不可接受
触发器的边界很清晰：它能保证“某事发生后立刻做某事”，但做不了“某事本身”。评分的复杂性、实时性、容错性，都得交给更适合的层去承担——SQL表达式处理规则型评分，外部服务处理模型型评分，触发器只负责精准传递信号。
