触发器无法直接踢掉已登录用户，只能在密码更新时清理user_sessions表中对应用户的未过期token，并更新last_password_change_at字段；强制下线需应用层校验token中的pwd_changed_at与数据库字段是否一致。
触发器本身不能直接踢掉已登录用户
SQL 触发器（比如 BEFORE UPDATE 或 AFTER UPDATE）运行在数据库服务端，它能修改数据、抛出异常、记录日志，但**无法主动断开应用层的连接或会话**。所谓“强制下线”，本质是让客户端后续请求失败（如校验 token 失效、session 过期），这必须由应用逻辑配合完成。触发器最多做到：标记用户密码已变、清空其有效 token 记录、或更新 last_password_change_at 字段供上层判断。
在 UPDATE users 密码时用 AFTER UPDATE 触发器清理 token 表
假设你用一张 user_sessions 表存登录态（含 user_id、token、expires_at 等字段），那么当 users.password_hash 被更新，就该让所有该用户的未过期 token 失效：
CREATE TRIGGER trg_invalidate_sessions_on_password_change AFTER UPDATE ON users FOR EACH ROW WHEN (OLD.password_hash IS DISTINCT FROM NEW.password_hash) BEGIN DELETE FROM user_sessions WHERE user_id = NEW.id AND expires_at > NOW(); END;
注意点：
- PostgreSQL 用
WHEN条件避免无意义触发；MySQL 需在触发器体内加IF OLD.password_hash != NEW.password_hash THEN ... END IF; - 别用
TRUNCATE或不带条件的DELETE，否则可能误删其他用户会话 - 确保
user_sessions.user_id有索引，否则高并发下DELETE可能成性能瓶颈
应用层必须配合校验「密码变更时间」防止 token 绕过
即使清空了旧 token，如果客户端还拿着一个长期有效的 JWT，且服务端只校验签名和过期时间，那它仍能继续访问。正确做法是在签发 token 时嵌入 pwd_changed_at 时间戳，并在每次请求中间件中比对：
例如 Express + JWT 场景：
if (token.pwd_changed_at > user.last_password_change_at) {
throw new Error('Token invalidated by password change');
}
关键点：
-
users表必须有last_password_change_at字段，并在触发器里同步更新：UPDATE users SET last_password_change_at = NOW() WHERE id = NEW.id; - 不要依赖 token 自身的
iat或exp做判断——它们和密码变更无关 - 若用 Redis 存 token 黑名单，触发器无法直接操作 Redis，得靠应用监听数据库变更（如通过 CDC）或改用应用层统一更新流程
MySQL 和 PostgreSQL 对触发器权限与事务行为处理不同
MySQL 的触发器在同一个事务中执行，能安全地读写同库表；PostgreSQL 的触发器函数默认是 SECURITY DEFINER，且不能在触发器里执行 COMMIT 或 ROLLBACK —— 所以清理 session 表的操作是原子的。但要注意：
- MySQL 8.0+ 支持在触发器中调用存储过程，但禁止在触发器中修改触发表本身（即不能在
UPDATE users触发器里再UPDATE users） - PostgreSQL 若用
BEFORE UPDATE想阻止弱密码，可用RAISE EXCEPTION；MySQL 则只能用SIGNAL SQLSTATE抛错 - 两者都不支持在触发器中发 HTTP 请求或调用外部服务——所以“通知网关下线”这类动作必须移出触发器
真正起作用的永远是应用和服务协同的那部分逻辑，触发器只是数据库侧的一个辅助钩子，别指望它单挑下线这件事。
