MySQL账号活跃度判断需依赖外部日志或主动埋点，因mysql.user无last_login字段；可靠方式包括开启general_log解析登录事件、使用audit_log、或结合created时间+password_expired+应用访问日志交叉验证。
MySQL账号活跃度怎么判断才靠谱
MySQL本身不记录账号的登录时间戳，mysql.user 表里的 password_last_changed 只反映密码修改时间，不是登录时间。真正能用的只有 performance_schema.account_statistics（MySQL 8.0.14+），但它默认关闭，且只统计连接数、语句数，不存最后登录时间。所以“长期未使用”必须靠外部日志或主动埋点——比如开启通用查询日志（general_log）并解析，或依赖审计插件（如 audit_log）输出的登录事件。
实操中更可行的做法是：结合账号创建时间 + 密码过期策略 + 应用层访问日志交叉验证。例如，若账号 created 字段是 2022-01-01，且 password_expired = 'Y'，又没在最近90天的应用访问白名单里出现过，基本可判定为闲置。
如何安全地批量锁定账号（非删除）
锁定账号本质是禁用其认证能力，但保留元数据和权限结构，便于后续恢复。MySQL 5.7.6+ 支持 ALTER USER ... ACCOUNT LOCK，这是最干净的方式；老版本只能靠清空密码或设为无效认证插件。
推荐操作步骤：
- 先查出目标账号：
SELECT User, Host FROM mysql.user WHERE account_locked = 'N' AND password_expired = 'Y' AND created < DATE_SUB(NOW(), INTERVAL 180 DAY);
- 生成锁定语句（注意
Host通配符需转义）：SELECT CONCAT('ALTER USER `', User, '`@`', Host, '` ACCOUNT LOCK;') AS stmt FROM mysql.user WHERE ...; - 执行前务必备份：
mysqldump -u root -p --no-data mysql user > user_meta_backup.sql
- 禁止直接
DROP USER—— 它会级联回收权限，且无法回滚已删的权限定义。
锁定后应用报错常见类型及应对
账号被锁后，客户端连接会立刻失败，典型错误是：ERROR 3097 (HY000): Account is locked（MySQL 8.0.14+）或老版本的 ERROR 1045 (28000): Access denied for user（无明确提示，容易误判为密码错）。
关键点：
- 应用连接池通常缓存失败连接，需重启或触发连接重建，否则持续报错；
- 某些ORM（如Laravel Eloquent）默认不重试，需手动加
options => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]才能捕获锁定异常； - 监控告警应区分
Access denied的子类型——可通过performance_schema.events_statements_summary_by_account_by_event_name中account_lock相关计数辅助识别。
为什么不能依赖 last_password_change 或 plugin 字段做判断
last_password_change 字段仅在启用密码策略（validate_password 插件）且用户主动改密时更新，管理员批量重置密码不会触发它；而 plugin 字段值为 caching_sha2_password 或 mysql_native_password，与活跃度完全无关。曾有团队误把 plugin = 'auth_socket' 当作“本地免密登录=高频使用”，结果锁掉了一批运维账号——因为 auth_socket 实际只用于 localhost 的系统用户，和业务活跃度零相关。
真正要盯的是：是否在最近一次全量慢查询日志中出现过该账号的 Connect 事件，以及对应应用服务是否还在配置文件里声明了该账号。
