MySQL密码过期机制：真的能自动强制修改密码吗？
先说结论：能，但绝非你想象的那种“全自动”——MySQL 8.0+ 的 PASSWORD EXPIRE 机制，会在用户下次登录后、执行第一条非 SET 语句时触发 ERROR 1820 错误，强制用户通过 ALTER USER IDENTIFIED BY 重置密码。但它不会像操作系统那样弹出提示窗口，也不会自动锁定账户。
换句话说，整个过程是“被动强制”：你成功登录进来了，但如果不修改密码，任何操作都无法执行。这好比你已经进了办公室，但办公桌被锁上了，前台告诉你：先去 HR 换张新门禁卡，才能开工。
MySQL 8.0+ 的密码过期机制：是否真的能自动强制改密？
不能。MySQL 自身不提供“到期自动锁定账户并弹窗提醒”这类操作系统级的干预能力。它只支持在创建或修改用户时，使用 PASSWORD EXPIRE 指令设定密码有效期（单位：天）。但到期后的行为，完全取决于客户端连接方式和服务器配置——默认情况下，用户仍然可以登录，只是每次登录会返回一条警告，而 SELECT 这类查询操作依然能正常执行。
这就引发了一个常见误解：很多人以为设置了密码过期，到期后账户就会被锁死。实际情况是——MySQL 给了你一张“通行证”，但进入后处处受限。
如何用 ALTER USER 设置密码 90 天后过期？
前提条件很明确：必须使用 MySQL 8.0.19 或更高版本，并且用户的认证插件必须支持密码过期（比如 caching_sha2_password）。如果用的是低版本（如 5.7）或者 mysql_native_password 插件，PASSWORD EXPIRE 设置会被直接忽略，甚至报错。
具体操作分三种场景：
- 设置用户
app_user密码90天后过期：ALTER USER 'app_user'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;
- 立即过期（下次登录必须改密）：
ALTER USER 'app_user'@'%' PASSWORD EXPIRE NOW;
- 取消过期策略：
ALTER USER 'app_user'@'%' PASSWORD EXPIRE NEVER;
需要注意的是，这些设置仅影响 MySQL 层面的行为，对应用层没有任何通知机制。你设定了密码过期，MySQL 不会主动给运维人员发送邮件，也不会在应用日志中写入“请通知用户修改密码”的提示。
登录后提示 “Your password has expired” 却无法改密？
这是最经典的一个坑。MySQL 要求用户在密码过期后首次登录时，必须使用 SET PASSWORD 或 ALTER USER 修改密码，否则后续所有语句——哪怕只是 SELECT 1——都会报错 ERROR 1862 (HY000): Your password has expired。但这里有一个关键前提：客户端没有启用 --skip-password，或者连接时没有指定新密码。
实际操作中的几种场景：
- 命令行登录后立即改密：
SET PASSWORD = 'NewPass@123';
- 如果权限不足，需要由管理员重置：
ALTER USER 'app_user'@'%' IDENTIFIED BY 'NewPass@123' PASSWORD EXPIRE INTERVAL 90 DAY;
- 应用连接池（比如 HikariCP、Druid）需要额外配置
allowPublicKeyRetrieval=true&serverTimezone=UTC，否则可能因为 RSA 密钥交换失败而卡在改密码环节。
这里特别要提醒的是：应用连接池的配置往往容易被忽略。一旦密码过期，应用层连接池里的所有连接都会失效，但连接池本身并不会主动去执行“改密”操作——它只会不断地重试，然后不断地收到 ERROR 1862，最终导致应用彻底不可用。这在生产环境中是非常棘手的问题。
为什么 SHOW CREATE USER 看不到 PASSWORD EXPIRE 设置？
很多人设置完密码过期后，习惯用 SHOW CREATE USER 来确认是否生效。结果发现——输出里根本没有 PASSWORD EXPIRE 相关的信息。
这不是 bug，而是 MySQL 的设计选择。SHOW CREATE USER 默认不显示密码过期策略，哪怕策略已经生效。要确认是否设置成功，需要查询 mysql.user 表的 password_expired 和 password_last_changed 字段：
SELECT user, host, password_expired, password_last_changed FROM mysql.user WHERE user = 'app_user';
注意：password_expired 是枚举值（'N'/'Y'），只反映当前是否已过期；真正控制策略的是 password_lifetime（全局变量）或用户级的显式设置，而这个字段根本不会出现在 SHOW CREATE USER 的输出中。
换句话说，MySQL 的密码过期机制更像是一个“单向开关”——你设置了，它生效，但不会告诉你它已经生效了。要确认，就得自己去查询系统表。
这也是整个密码过期机制里最难处理的问题：跨服务协同。MySQL 不会通知应用层“该修改密码了”，也不会触发任何回调函数。靠人工监控日志、或者编写定时脚本轮询 mysql.user 表，才是实际落地时绕不开的工作。如果你在生产环境里真正用过这个功能，就会明白——它不是功能不够好，而是需要你把它和外部监控、应用配置、运维流程串接起来，才能形成完整的密码管理闭环。
