在业务系统里，用户偏好往往需要根据点击、收藏、搜索等交互行为实时调整。如果完全依赖后端脚本定时计算，不仅存在分钟级延迟，还会在批量更新时给主库带来突发压力。利用数据库自身的触发器机制，可以在交互数据写入的那一刻就完成偏好值的修正，让数据状态始终保持最新。
触发器捕捉交互数据的基本原理
触发器是数据库在表发生 insert、update 或 delete 操作时自动执行的一段过程化代码。对于用户偏好自动更新场景，我们通常会在交互记录表（例如 user_action_log）上创建 after insert 触发器。每当有一条新交互写入，触发器就会根据动作类型与权重，去更新 user_preference 表中对应用户的字段。
这种方式的本质是把“行为到偏好”的映射规则下沉到存储层。应用端只需要正常插入交互日志，不需要关心偏好如何变化。相比在应用代码中显式调用更新逻辑，触发器避免了多处业务代码重复实现偏好算法，也防止了某些分支漏写更新语句而导致数据不一致。
需要注意的是，触发器内的逻辑应尽量轻量。如果在触发器中做复杂查询或跨表大量更新，会显著拉长原事务的提交时间。一般建议只做单行或少量几行的确定性计算，例如给某个兴趣标签的得分加一，或将最近交互时间刷新为当前时间。
MySQL 与 PostgreSQL 的实现示例
下面以 MySQL 为例，展示如何创建交互表、偏好表以及对应的触发器。假设用户每次点赞某个分类的内容，就为该分类偏好加分。
-- 用户偏好表
CREATE TABLE user_preference (
user_id INT PRIMARY KEY,
category_id INT,
score INT DEFAULT 0,
last_active DATETIME
);
-- 交互日志表
CREATE TABLE user_action_log (
id INT AUTO_INCREMENT PRIMARY KEY,
user_id INT,
category_id INT,
action_type VARCHAR(20),
create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- 点赞后更新偏好的触发器
DELIMITER $$
CREATE TRIGGER trg_after_action_insert
AFTER INSERT ON user_action_log
FOR EACH ROW
BEGIN
IF NEW.action_type = 'like' THEN
INSERT INTO user_preference (user_id, category_id, score, last_active)
VALUES (NEW.user_id, NEW.category_id, 1, NEW.create_time)
ON DUPLICATE KEY UPDATE score = score + 1, last_active = NEW.create_time;
END IF;
END$$
DELIMITER ;
在 PostgreSQL 中，触发器需要绑定一个函数。写法略有不同，但思路一致：函数内部通过 TG_OP 判断操作类型，使用 NEW 伪记录获取插入行数据。
CREATE TABLE user_preference (
user_id INT PRIMARY KEY,
category_id INT,
score INT DEFAULT 0,
last_active TIMESTAMP
);
CREATE TABLE user_action_log (
id SERIAL PRIMARY KEY,
user_id INT,
category_id INT,
action_type TEXT,
create_time TIMESTAMP DEFAULT NOW()
);
CREATE OR REPLACE FUNCTION fn_update_preference()
RETURNS TRIGGER AS $$
BEGIN
IF NEW.action_type = 'like' THEN
INSERT INTO user_preference (user_id, category_id, score, last_active)
VALUES (NEW.user_id, NEW.category_id, 1, NEW.create_time)
ON CONFLICT (user_id) DO UPDATE
SET score = user_preference.score + 1, last_active = NEW.create_time;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trg_after_action_insert
AFTER INSERT ON user_action_log
FOR EACH ROW EXECUTE FUNCTION fn_update_preference();
上述代码均使用了 upsert 语义，确保用户首次出现时创建偏好行，后续则累加分数。这样的结构在读写分离架构中也能正常工作，只要写入落在主库即可。
性能影响与避坑建议
触发器虽然方便，但也会带来写放大问题。每一次交互插入都会额外触发一次偏好更新，若交互量极大，主库写入压力会翻倍。此时可以考虑将得分更新改为批量合并，或在触发器内只写消息队列，由异步消费者更新偏好，从而把同步开销降到最低。
另一个常见误区是以为触发器能完全替代业务层逻辑。实际上，涉及多步校验、调用外部接口或需要事务补偿的场景，仍应在应用层完成。触发器适合做确定性的、无副作用的数据派生，不适合承载核心业务规则。
此外，在并发较高的系统中，偏好表的行锁可能成为瓶颈。如果同一用户高频互动，触发器会反复更新同一行，造成锁等待。可以通过应用层合并短时交互、或采用 Redis 计数再定时落库来缓解。理解这些边界，才能稳妥地把用户偏好自动更新交给触发器处理。
SQL_triggeruser_preferenceinteraction_data修改时间：2026-08-16 11:36:12