触发器无法直接登出用户，只能记录密码变更供应用层感知；登出逻辑必须由业务层实现，如JWT校验时比对password_version字段。
触发器本身不能直接登出用户
SQL 触发器运行在数据库服务端，它没有能力操作应用层的会话状态（比如 JWT token、session ID、浏览器 cookie 或 WebSocket 连接）。所谓“强制登出”，本质是让客户端后续请求被拒绝——这必须由应用代码配合实现。触发器最多能做的，是记录密码变更事实，供应用层轮询或监听。
常见错误现象：UPDATE users SET password = 'new' WHERE id = 1 执行后，触发器里写 UPDATE sessions SET valid = 0 WHERE user_id = NEW.id —— 这看似合理，但前提是你的应用真正在每次请求时校验 sessions.valid 字段；否则，这条更新毫无作用。
- 触发器适合做副作用记录（如写日志表、更新
users.last_password_change时间戳） - 登出逻辑必须下沉到业务层：API 网关、认证中间件、或登录态校验函数中
- 如果用 Redis 存 session，触发器无法直接删 key（数据库和 Redis 是隔离的）
用触发器标记密码变更并通知应用层
最务实的做法：触发器只负责更新一个轻量字段，让应用层能低成本感知变化。例如给 users 表加 password_version 整数列，每次密码更新就 SET password_version = password_version + 1。
示例触发器（MySQL）：
CREATE TRIGGER after_password_update
AFTER UPDATE ON users
FOR EACH ROW
IF OLD.password != NEW.password THEN
UPDATE users SET password_version = password_version + 1 WHERE id = NEW.id;
END IF;
- 避免用
NOW()或UNIX_TIMESTAMP()当版本号——并发修改可能导致时间相同，版本未变 - 应用层在验证 token 时，查当前用户的
password_version，比对 token payload 中携带的旧值 - 这个字段还能用于乐观锁式密码重置校验，一石二鸟
应用层如何基于触发器结果做登出判断
关键不是“怎么写触发器”，而是“怎么让应用读得快、判得准”。假设你用 Express + JWT：
- 登录成功时，把
user_id和当前password_version一起塞进 token payload - 每次受保护接口前，用
SELECT password_version FROM users WHERE id = ?查最新值 - 若 token 中的
password_version401 Unauthorized，不需清 session（stateless） - 别在每次请求都查数据库：可缓存
user_id → password_version到 Redis，设置 5 分钟 TTL，命中率高且一致性强
注意：不要在触发器里发 HTTP 请求或调用外部服务——事务上下文里做这些极不可靠，容易卡住整个事务。
替代方案：为什么多数场景该放弃触发器
除非你无法修改应用代码（比如维护遗留系统），否则直接在密码修改的业务逻辑里同步失效 session 更简单、更可控。
- 改密码接口里，删 Redis 的
session:{token}和user_sessions:{user_id}两个 key - 用消息队列广播 “user_x_password_changed”，多个服务各自清理本地缓存
- 前端登出按钮点击后，主动清 localStorage + 调用
/auth/logout接口，比等后端被动踢更及时
触发器引入额外的耦合点和调试成本。真正难的从来不是“怎么让数据库知道密码变了”，而是“怎么让所有在线终端立刻感知并响应”。这件事，数据库不该也不擅长做。
