mysql如何设置密码过期策略_配置default_password_life

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 或特定的认证插件触发密码变更时，它才会被刷新。这一点在功能测试时特别容易遗漏，务必引起重视。