MySQL不记录最后登录时间，真正能查认证成功的只有performance_schema.accounts表的LAST_SEEN字段，但需先启用accounts消费者；新账号从未登录则不会出现在该表中；锁定应优先用ALTER USER ... ACCOUNT LOCK，避免直接DROP USER；“半死账号”需满足account_locked='Y'、所有权限为'N'且authentication_string为空或无效哈希。
直接锁定长期未使用的账号不可行——MySQL 不记录最后登录时间，mysql.user 表里没有 last_login 字段，所谓“长期未用”必须靠外部证据或变通推断，否则锁错账号风险极高。
怎么查“真正没登录过”的账号（performance_schema.accounts）
MySQL 8.0+ 唯一能反映认证成功时间的是 performance_schema.accounts 表的 LAST_SEEN 字段，但它默认不启用，且新账号从未登录就不会出现在这张表里。
- 先确认是否启用：
SELECT VARIABLE_VALUE FROM performance_schema.setup_consumers WHERE NAME = 'accounts';，返回NO就得手动开：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'accounts'; -
LAST_SEEN是最后一次成功认证时间，不是连接活跃时间；events_connections_history_long才存EVENT_TYPE='connect'的原始记录，但默认关闭、性能开销大，生产环境慎用 - 查 90 天没连过的非系统账号：
SELECT USER, HOST FROM performance_schema.accounts WHERE USER NOT IN ('mysql.session', 'mysql.sys', 'root') AND LAST_SEEN < DATE_SUB(NOW(), INTERVAL 90 DAY); - 注意：结果为空 ≠ 没有僵尸账号，而是这些账号压根没被“看见”过（即创建后从未成功登录）
怎么安全锁定（别删，优先用 ACCOUNT LOCK）
锁定比删除稳妥得多，保留元数据、权限关系和角色绑定，便于回滚或审计。直接 DROP USER 在应用硬编码、连接池复用或定时脚本引用时极易引发故障。
- 锁定命令必须带完整
User@Host格式：ALTER USER 'xxx'@'yyy' ACCOUNT LOCK;，漏掉@'yyy'或写成'xxx'@'%'但实际是'xxx'@'10.1.2.3'都会失败 - 不能用
UPDATE mysql.user SET account_locked = 'Y'—— 这样改了也不生效，下次FLUSH PRIVILEGES或重启可能被覆盖 - 锁定后用户无法新建连接，但已有长连接（如应用连接池里的活跃会话）不受影响，需重启应用或触发连接重建才能真正断开
- 验证是否真锁住，不能只看
account_locked = 'Y'，要实测登录：mysql -u xxx -p -h your-host，应报ERROR 3118 (HY000): Access denied for user 'xxx'@'%' (Account is locked)
怎么识别“半死账号”（account_locked = 'Y' 且权限全无）
有些账号早被 REVOKE 全部权限、又 ACCOUNT LOCK，但一直没清理，卡在 mysql.user 里占位。这类账号满足三个条件，可批量揪出：
account_locked = 'Y'- 所有基础权限字段（
Select_priv、Insert_priv、Update_priv、Delete_priv等）全为'N' -
authentication_string为空，或匹配无效哈希（如'*0'或'*1'） - 执行这句筛选：
SELECT User, Host FROM mysql.user WHERE account_locked = 'Y' AND Select_priv = 'N' AND Insert_priv = 'N' AND Update_priv = 'N' AND Delete_priv = 'N' AND Create_priv = 'N' AND Drop_priv = 'N' AND Reload_priv = 'N' AND Shutdown_priv = 'N' AND Process_priv = 'N' AND File_priv = 'N' AND Grant_priv = 'N' AND References_priv = 'N' AND Index_priv = 'N' AND Alter_priv = 'N' AND Show_db_priv = 'N' AND Super_priv = 'N' AND Create_tmp_table_priv = 'N' AND Lock_tables_priv = 'N' AND Execute_priv = 'N' AND Repl_slave_priv = 'N' AND Repl_client_priv = 'N' AND Create_view_priv = 'N' AND Show_view_priv = 'N' AND Create_routine_priv = 'N' AND Alter_routine_priv = 'N' AND Create_user_priv = 'N' AND Event_priv = 'N' AND Trigger_priv = 'N' AND Create_tablespace_priv = 'N' AND ssl_type = '' AND authentication_string IN ('', '*0', '*1');
为什么不能依赖 FAILED_LOGIN_ATTEMPTS 自动锁“僵尸账号”
FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 是防暴力破解的机制，不是判断“长期未用”的工具——它只在连续输错密码后触发，跟账号是否闲置毫无关系。
- 必须成对设置才生效，单独设
FAILED_LOGIN_ATTEMPTS 3不会锁任何账号 - 只对
caching_sha2_password或mysql_native_password认证用户有效，auth_socket或 LDAP/PAM 外部认证下完全无效 -
PASSWORD_LOCK_TIME单位是天，写0是永久锁定，不是关闭锁定 - 锁定期满不会自动解锁，必须有一次成功登录才会重置计数；若一直没人试，就永远锁着
- MySQL 5.7.6+ 初步支持，但 5.7.17 前版本语法不识别，8.0.19+ 才稳定
真正麻烦的不是怎么锁，而是怎么确认该不该锁——生产环境里，很多账号本就该长期闲置（比如模板账号、灾备账号、合规保留账号），盲目按“90天没登录”一刀切，反而会踩进权限回收、角色失效、代理关系断裂的坑里。
