触发器不能直接更新被修改的表，应将行为日志写入独立表 user_events，通过异步任务或 ON CONFLICT upsert 更新 user_preferences，并加入时间衰减与行为阈值控制偏好计算。
触发器能实时捕获用户行为，但不能直接更新同一张表
MySQL 和 PostgreSQL 的 BEFORE UPDATE 或 AFTER INSERT 触发器确实能监听用户点击、浏览、搜索等操作日志，但若日志表（如 user_events）和偏好表（如 user_preferences）是同一张表，或触发器里尝试对被修改的表再做 UPDATE，会直接报错：Can't update table 'user_preferences' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.
实操建议：
- 把原始行为日志写入独立表
user_events（含user_id、event_type、item_id、created_at） - 触发器定义在
user_events上，仅做「记录后处理」，比如调用存储过程或写入中间队列表 - 真正更新
user_preferences应由异步任务（如定时 job 或消息消费者）完成，避免锁表和递归限制
PostgreSQL 中用 INSERT ... ON CONFLICT 替代复杂触发器逻辑
如果只是想根据新事件累加偏好权重（例如：每点击一次商品，preference_score +1），硬写触发器反而容易出错。PostgreSQL 支持原子化 upsert，更安全高效。
示例：用户点击商品后，更新其对该类目的偏好分
INSERT INTO user_preferences (user_id, category_id, preference_score) VALUES (123, 45, 1) ON CONFLICT (user_id, category_id) DO UPDATE SET preference_score = user_preferences.preference_score + EXCLUDED.preference_score;
注意点：
-
ON CONFLICT必须有唯一约束支撑，比如在(user_id, category_id)上建UNIQUE INDEX -
EXCLUDED是 PostgreSQL 特有关键字，代表本次插入中被冲突拦截的那行数据 - 这个语句可直接在应用层执行，无需触发器，也规避了事务嵌套问题
MySQL 触发器里不能调用存储函数修改表，但可用 INSERT DELAYED（已弃用）或转向事件驱动
MySQL 8.0+ 不支持在触发器中调用含 UPDATE 的存储函数，INSERT DELAYED 也早在 5.6 被标记废弃。强行绕过会导致不可靠或主从不一致。
可行路径：
- 触发器只向一张轻量级「信号表」
preference_update_queue插入记录（字段：user_id, reason, updated_at） - 用 MySQL Event 定时（如每 30 秒）扫描该表，批量合并更新
user_preferences，再清空队列 - 或者将信号表变更作为 binlog 事件，用外部工具（如 Debezium + Kafka）投递到 Python/Go 服务做聚合计算
偏好更新不是越实时越好——要防高频抖动和冷启动偏差
用户连续点击 5 次同个按钮，不代表他真喜欢这个功能；新注册用户没任何行为，也不能让推荐系统直接喂默认热门内容。
关键控制点：
- 在聚合层加入时间衰减：最近 1 小时的行为权重 ×2，24 小时内 ×1，7 天外 ×0.3
- 设置最小行为阈值，比如
user_events中某用户近 7 天事件数 - 对
preference_score加软上限（如 ≤100），避免单次爆发行为扭曲长期画像
这些规则放在触发器里很难维护，更适合在下游 ETL 或特征服务中统一实现。
