MySQL密码过期策略全面解析：从全局配置到用户级管理的实战指南
首先需要明确一个核心概念：default_password_lifetime 是 MySQL 5.7.4 及以上版本中，用于控制新创建用户默认密码有效期的全局系统变量，其计量单位是天。然而，这个变量存在一个至关重要的限制——它仅对新创建的用户账户生效，对数据库中已存在的用户没有任何影响。若要让现有用户的密码也遵循过期策略，必须使用 ALTER USER 语句进行显式配置。
default_password_lifetime 详解与常见失效原因
简而言之，default_password_lifetime 是 MySQL 自 5.7.4 版本起引入的全局变量，专门用于设定新账户的默认密码生存周期。然而，它最显著的特性，也恰恰是运维工作中最常见的误区：此变量仅作用于“新建用户”，对数据库内已有的存量用户完全无效。
一个典型的运维失误场景如下：管理员执行了 SET GLOBAL default_password_lifetime = 90; 命令，系统提示设置成功。但随后检查时发现，现有用户登录时一切正常，既未收到强制修改密码的提示，密码也未显示过期迹象。问题的根源在于，该变量的设计初衷就是管理“新生”账户，而非“存量”账户。
- 要真正落实全库密码策略，必须结合
CREATE USER或ALTER USER命令，为每个用户进行显式设定。 - 从 MySQL 8.0.19 版本开始，此变量的默认值从 0（代表永不过期）调整为 360（即360天），但这一变更同样只适用于此后新建的用户。
- 关于参数取值：设置为 0 表示该用户密码永不过期；设置为 NULL 则表示该用户继承全局的
default_password_lifetime设置。
如何为现有用户配置密码过期策略（ALTER USER 实战用法）
那么，如何为数据库中已有的“存量”用户强制实施密码过期策略呢？答案是，不要期望通过修改全局变量来实现，必须使用 ALTER USER 命令进行显式指定。这是目前最可靠且标准的方法。
此方法在以下场景中尤为实用：运维团队进行批量账户安全加固时、为满足合规审计要求必须定期轮换密码时，或在测试环境中需要模拟密码过期流程时。
ALTER USER 'app_user'@'%' PASSWORD EXPIRE;—— 这是最“立竿见影”的方式，直接令密码立即过期，用户下次登录时必须更改密码。ALTER USER 'app_user'@'%' PASSWORD EXPIRE INTERVAL 180 DAY;—— 相对温和的方式，设定密码在180天后过期。ALTER USER 'app_user'@'%' PASSWORD EXPIRE NEVER;—— 取消该用户的密码过期策略。请特别注意，取消过期的关键字是NEVER，而非DEFAULT。- 执行上述命令后无需重启MySQL服务，更改会立即生效。但需注意，它只影响用户下一次的认证过程，当前已建立的数据库连接不受影响。
如何查看用户密码过期状态及剩余有效天数
配置完成后，如何验证效果并查看状态呢？MySQL并未直接提供类似“days_until_expire”的字段来直观显示密码剩余天数。但我们可以通过查询 mysql.user 系统表，或使用 SHOW CREATE USER 命令来推断当前状态。
判断的关键，在于 password_expired 和 password_last_changed 这两个核心字段。
- 最直接的查询语句：
SELECT user, host, password_expired, password_last_changed FROM mysql.user WHERE user = 'app_user'; - 查看用户创建语句：
SHOW CREATE USER 'app_user'@'%';—— 如果输出结果中包含PASSWORD EXPIRE或PASSWORD EXPIRE INTERVAL子句，则说明已配置过期策略。 - 需要注意一个细节：
password_last_changed字段记录的是UTC时间。如需计算剩余天数，需手动结合default_password_lifetime的值进行计算，因为MySQL本身不提供自动计算剩余天数的功能。 - 此外，请勿混淆概念。MySQL 8.0.19+ 版本引入了
password_reuse_history（密码重用历史）和password_reuse_time（密码重用时间）等策略，它们管理的是密码能否被重复使用，与密码是否过期是两个独立的安全维度。
密码过期策略在主从复制与集群环境中的行为差异
在部署了主从复制或集群架构的生产环境中，密码过期策略的行为会存在一些差异。密码过期信息属于用户元数据的一部分，理论上会通过DDL语句同步到从库，但在同步时机和权限处理上，存在一些需要特别注意的细节。
理解这些差异，对于在高可用集群中统一管理账户生命周期、避免出现主库密码已过期但从库仍可登录的权限不一致问题，至关重要。
ALTER USER ... PASSWORD EXPIRE是一条标准的DDL语句，它会被写入二进制日志（binlog），从而在从库回放时同样生效。- 但是，如果从库设置了
read_only=ON（只读模式），并且执行复制操作的用户在从库上没有SUPER权限，那么这条ALTER USER命令在从库回放时可能会报错：ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement。 - 解决方案通常有两种：要么临时关闭从库的
read_only模式（通常不推荐，存在安全风险），要么在拥有相应权限的情况下，手动在从库上再次执行相同的ALTER USER命令。 - 还需要了解的是，如ProxySQL、MHA这类数据库中间件或高可用工具，它们本身并不感知MySQL内部的密码过期逻辑。因此，它们既不会拦截过期连接，也不会给出相关提示，密码过期的触发完全依赖于客户端直接连接MySQL服务器时的认证过程。
最后，分享一个实战中容易被忽略的关键点。真正的挑战往往不在于设置几个参数，而在于深刻理解两个底层机制：第一，default_password_lifetime 对老用户完全无效；第二，password_last_changed 这个时间戳不会自动刷新。例如，如果用户使用 SET PASSWORD 命令修改密码，该字段并不会更新。只有通过 ALTER USER ... IDENTIFIED BY 或特定的认证插件触发密码变更时，它才会被刷新。这一点在功能测试时特别容易遗漏，务必引起重视。
