查 mysql.user 表的 account_locked 字段是确认手动锁定的最准方法：y 表示已被手动锁定，n 不代表安全，还需结合 information_schema.user_attributes 检查自动锁定策略及 error 3956 报错验证。
查 account_locked 字段确认是否已被手动锁定
直接查 mysql.user 表是最准的起点，因为只有这个字段能明确告诉你“管理员是否执行过 ACCOUNT LOCK”。SHOW GRANTS FOR 'u'@'h' 完全不返回锁定状态，别被它误导。
-
SELECT user, host, account_locked FROM mysql.user WHERE user = 'baduser';—— 返回Y表示已手动锁定；N不代表安全，可能只是没锁，也可能正被自动策略锁定（见下一条） - MySQL 5.7 及更早版本没有
account_locked字段，这种环境下所谓“锁定”全是靠插件模拟或外部脚本实现，原生不可查 - 如果查出来是
Y，但你没执行过锁定操作，说明有其他 DBA 或自动化任务干的，得翻操作记录
用 INFORMATION_SCHEMA.USER_ATTRIBUTES 查自动锁定策略是否生效
MySQL 8.0.22+ 把 FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 存在 INFORMATION_SCHEMA.USER_ATTRIBUTES 的 JSON 字段里，mysql.user 表不更新这个值。只查 account_locked = 'N' 就断定“没锁”，会漏掉真被自动锁定的用户。
SELECT User, Host, ATTRIBUTE->>'$.failed_login_attempts' AS max_tries, ATTRIBUTE->>'$.password_lock_time' AS lock_time FROM INFORMATION_SCHEMA.USER_ATTRIBUTES WHERE User = 'baduser';- 如果
max_tries是非零值（比如"5"），且该用户近期输错密码 ≥5 次，那账号大概率已触发自动锁定，但account_locked仍为N -
lock_time是字符串，值为"UNBOUNDED"表示永久锁死，只能人工ALTER USER ... ACCOUNT UNLOCK
执行 ALTER USER ACCOUNT LOCK 才算真正锁住
别 UPDATE mysql.user 表，也别指望改系统变量就能锁账号——MySQL 8.0+ 明确要求必须用 ALTER USER 命令，否则权限缓存不一致，甚至导致后续无法登录。
- 锁定命令：
ALTER USER 'baduser'@'%' ACCOUNT LOCK; - 解锁命令：
ALTER USER 'baduser'@'%' ACCOUNT UNLOCK; - 执行后无需
FLUSH PRIVILEGES，MySQL 8.0+ 会自动重载权限系统 - 注意：如果该用户同时配置了
FAILED_LOGIN_ATTEMPTS，ACCOUNT LOCK会优先生效，失败计数器直接不启动
ERROR 3956 是唯一可信的锁定报错信号
“Access denied for user” 错误太模糊，背后可能是密码错、host 不匹配、plugin 不兼容、密码过期、账号锁定……光看错误码 1045 (28000) 根本无法定位。
- 真正由账户锁定引发的错误是：
ERROR 3956 (HY000): Account is locked - 这个错误只在
ACCOUNT LOCK生效时出现；自动锁定（FAILED_LOGIN_ATTEMPTS）失败时仍报1045，但错误日志里会有 “Account is locked” 提示行 - 所以巡检脚本不能只抓
1045就发告警，得结合日志解析 +USER_ATTRIBUTES查询 + 实际连接测试才能判准
account_locked = 'Y' 状态，自动化脚本一扫就告警，反而掩盖真实风险。判断异常用户前，先确认账号用途和生命周期，比查字段值更重要。
