MySQL 8.0+密码过期策略详解：必须使用ALTER USER设置，SET PASSWORD为何无效？其核心是更新mysql.user表的元数据字段
ALTER USER PASSWORD EXPIRE 正确语法解析，SET PASSWORD 为何无效？
理解MySQL 8.0及以上版本的密码过期策略，关键在于区分其本质：它是一个独立于密码哈希值的账户元数据标记。当你仅使用 SET PASSWORD 命令时，操作仅会更新用户的密码哈希值，而完全不会触及 mysql.user 系统表中的关键字段，如 password_expired 或 password_lifetime。这导致密码虽然被修改，但过期策略并未被激活或更新，用户账户的密码管理状态保持不变。
因此，正确配置密码过期策略的唯一方法是使用 ALTER USER 命令，并配合 PASSWORD EXPIRE 子句。以下是几种核心应用场景的语法示例：
ALTER USER 'dev'@'10.%.%' PASSWORD EXPIRE;—— 此命令立即使指定用户的密码状态变为过期。用户下次成功认证后，在执行第一条非SET类型的SQL语句时，将立即收到ERROR 1820 (HY000)错误，提示必须重置密码。ALTER USER 'dev'@'10.%.%' PASSWORD EXPIRE INTERVAL 45 DAY;—— 为用户设置一个45天的密码有效期，从设置时刻开始倒计时，到期后自动触发过期。ALTER USER 'dev'@'10.%.%' PASSWORD EXPIRE NEVER;—— 此命令并非设置“永不过期”，而是直接移除该用户账户上的密码过期策略，使其不受全局或默认过期规则约束。
需要特别注意一个常见的兼容性陷阱：在自动化脚本或旧版迁移中，可能会误用如 SET PASSWORD FOR 'u'@'h' = PASSWORD('x') 的语法。请务必注意，PASSWORD() 函数在MySQL 8.0中已被彻底移除，且此类 SET PASSWORD 语句完全不会更新任何与密码过期相关的元数据字段。
default_password_lifetime 全局变量详解：仅影响新建用户默认值
许多数据库管理员对全局系统变量 default_password_lifetime 的作用范围存在误解。该变量的职责非常清晰且有限：它仅为那些通过 CREATE USER 语句新建、且未在创建时显式指定 PASSWORD EXPIRE 选项的用户账户，提供一个默认的密码生命周期。对于数据库中已存在的任何用户，此全局变量的更改均不产生直接影响。例如，即使你将全局默认值调整为30天，用户 alice 的密码过期时间仍将维持其上一次通过 ALTER USER 单独设定的值，不会自动同步更新。
在实际运维中，可以参考以下操作指南：
- 查询当前的全局默认过期设置：
SELECT @@global.default_password_lifetime; - 如需永久性更改全局默认值（配置将持久化至
mysqld-auto.cnf）：SET PERSIST default_password_lifetime = 90; - 若希望所有新创建账号默认60天后过期，同时保留为关键账号（如DBA账户）手动设置豁免的灵活性，则不应将全局值设为
0（即永不过期）。 - 对于批量更新所有现有用户的密码过期策略，MySQL并未提供内置的一键命令，需要通过编写脚本循环执行
ALTER USER ... PASSWORD EXPIRE INTERVAL 60 DAY语句来实现。
密码过期触发机制揭秘：并非登录时拦截，而是在执行SQL时检查
MySQL密码过期的触发机制存在一个容易令人困惑的细节：许多人误以为设置 PASSWORD EXPIRE 后，用户在建立连接时就会被拒绝或收到强制改密提示。实际上，MySQL的运作逻辑如下：
- 用户使用尚未更改的旧密码成功通过身份认证，连接正常建立。
- 连接建立后，只要用户不执行任何非
SET类型的SQL语句（例如SELECT、INSERT、SHOW TABLES等），密码过期的状态检查就不会被触发。 - 当用户尝试执行第一条非
SET语句时，服务器会立即返回ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.错误。 - 在此期间，纯粹的
SET语句，如SET NAMES utf8mb4、SET autocommit = 1等，仍可正常执行。
这一机制带来的影响是：在长连接保持空闲、应用连接池复用现有连接、或客户端自动发送 SET 语句进行健康检查的场景下，密码已过期的事实可能会被“隐藏”相当长的时间。真正强制用户修改密码的时机，被延迟到了用户首次尝试执行实际业务操作的那一刻。
MySQL 5.7 版本兼容性说明：不支持原生密码过期语法
必须明确指出，MySQL 5.7 版本并不原生支持 ALTER USER ... PASSWORD EXPIRE 语法。若在5.7环境中直接执行该命令，将收到明确的语法错误。许多网络教程直接引用8.0的语法，在5.7版本中是完全无效的。
那么，在MySQL 5.7环境下，如果希望实现类似的定期密码轮换安全效果，可行的替代方案主要有两种：
- 在应用层或外部运维平台部署定期任务脚本，通过调用如
mysql -e "ALTER USER 'u'@'h' IDENTIFIED BY 'newpass'"的命令来强制修改密码，并详细记录操作日志。这本质上是一种基于时间计划驱动的人工密码轮换机制。 - 利用MySQL内置的事件调度器（
mysql_event）结合自定义存储过程，定期查询mysql.user表中的password_last_changed字段，对超过指定期限的账户执行告警通知，或在极端安全策略下，通过执行REVOKE ALL PRIVILEGES ON *.* FROM 'u'@'h'来临时锁定账户权限（但需注意，此操作不阻止账户登录，仅限制其执行操作）。
请避免走入误区：调整 validate_password_length 或 validate_password_policy 等插件参数是无效的，这些参数仅用于校验密码的复杂度和强度，与“密码到期强制修改”这一时间维度的策略完全无关。
最后补充几个关键要点：MySQL 8.0.19+ 版本引入的 PASSWORD EXPIRE NEVER 选项，是一个用户级别的豁免开关，并非全局开关；它仅对指定用户生效，全局默认策略对其他用户依然有效。此外，如果系统表未正确升级（例如从MySQL 5.7升级到8.0后未运行 mysql_upgrade 工具），会导致 mysql.user 表结构不完整，缺少必要的字段，进而使得所有密码管理操作失败。错误日志中通常会提示 Column count of mysql.user is wrong —— 这个问题比单纯的语法错误更为隐蔽，且影响范围更广。
