mysql触发器无法拦截登录行为，因login非dml/ddl操作；登录失败锁定需应用层记录失败次数，并通过before update触发器自动设置locked_until字段，同时须配套成功登录清零、原子计数及超时校验机制。
MySQL触发器无法直接拦截登录行为
触发器不能用于实现登录失败锁定——因为 LOGIN 不是 MySQL 的 DML 或 DDL 操作，没有对应事件可监听。MySQL 触发器只响应 INSERT、UPDATE、DELETE 和某些版本的 REPLACE，不响应认证过程。
所谓“登录失败锁定”，本质是应用层或数据库访问控制层的行为。你真正能干预的位置只有：用户密码校验失败后，由应用记录失败次数；或在用户表上对 UPDATE（比如更新 failed_login_count 或 locked_until）做响应。
用 AFTER UPDATE 触发器自动维护锁定状态
假设你在 users 表中维护了 failed_login_count 和 locked_until 字段，当应用检测到登录失败时执行一次 UPDATE，就可以用触发器自动处理锁定逻辑：
CREATE TRIGGER tr_after_user_failed_login
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.failed_login_count != NEW.failed_login_count
AND NEW.failed_login_count >= 5 THEN
SET NEW.locked_until = DATE_ADD(NOW(), INTERVAL 15 MINUTE);
END IF;
END;
- 必须确保应用层每次失败都显式更新
failed_login_count，否则触发器不会被调用 - 触发器里不能修改
NEW的值（BEFORE UPDATE才可以），所以这里用AFTER只作状态同步或日志，真要自动设锁定时间得换BEFORE UPDATE - 如果用
BEFORE UPDATE，需注意避免无限循环：比如在触发器里又去UPDATE users同一行
BEFORE UPDATE 触发器实现自动锁定计算
更实用的做法是把锁定逻辑放在 BEFORE UPDATE 中，让应用只需更新 failed_login_count，其余由触发器兜底：
DELIMITER $$
CREATE TRIGGER tr_before_user_update_lock
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF NEW.failed_login_count > OLD.failed_login_count THEN
IF NEW.failed_login_count >= 5 THEN
SET NEW.locked_until = DATE_ADD(NOW(), INTERVAL 15 MINUTE);
ELSE
SET NEW.locked_until = NULL;
END IF;
END IF;
END$$
DELIMITER ;
- 这个触发器只在
failed_login_count增加时生效，避免误触发 -
SET NEW.locked_until是合法的，因为发生在写入前 - 记得在
users表中为locked_until字段定义为DATETIME NULL，否则NULL赋值会报错 - MySQL 8.0+ 支持
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，但不适用于动态计算场景，仍需触发器
实际部署时最容易忽略的三个点
这套逻辑上线后常出问题，不是语法错，而是设计盲区：
- 没有配套的「成功登录清零」机制：应用必须在验证通过后执行
UPDATE users SET failed_login_count = 0, locked_until = NULL WHERE id = ?，否则锁永远不解 - 并发登录失败可能造成计数错乱：两个请求同时读到
failed_login_count = 4，各自 +1 写回，结果变成 5 而非 6；建议用UPDATE ... SET failed_login_count = failed_login_count + 1原子操作 - 触发器不处理超时自动解锁：
locked_until是静态时间戳，应用每次登录前必须先查locked_until 才决定是否允许尝试，触发器对此无能为力
真正健壮的方案，是把计数、锁定、解锁全交给应用控制，触发器只作为辅助审计或兜底同步；过度依赖触发器会让逻辑分散、难以测试、排查困难。
