alter user是唯一有效设置密码过期的方式，update mysql.user表直接修改password_expired字段无效且危险；该字段仅为只读状态快照，真实策略由alter user子句联动更新并驱动校验逻辑。
ALTER USER 是唯一能改 password_expired 的方式
直接 UPDATE mysql.user 表的 password_expired 字段是无效且危险的。MySQL 8.0 不允许手动写入该字段，即使你有 SUPER 权限，执行 UPDATE mysql.user SET password_expired = 'Y' WHERE User = 'test' 后，下次登录也不会触发强制重置——因为服务端校验逻辑只认 ALTER USER ... PASSWORD EXPIRE 所产生的元数据状态，包括 password_last_changed 和内部策略标记。
真正生效的操作只有：
-
ALTER USER 'test'@'localhost' PASSWORD EXPIRE;→ 立即过期 -
ALTER USER 'test'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;→ 90 天后过期 -
ALTER USER 'test'@'localhost' PASSWORD EXPIRE NEVER;→ 取消过期
注意：PASSWORD EXPIRE DEFAULT 不等于“不过期”，而是继承 @@default_password_lifetime 的值，容易误判。
为什么查到 password_expired = 'Y' 却没被拦截？
看到 SELECT User, Host, password_expired FROM mysql.user WHERE User = 'test' 返回 'Y'，不代表用户当前就处于“必须改密”状态。真实拦截逻辑还依赖两个条件：
- 用户没有
ALTER USER权限（有该权限可跳过重置） -
@@default_password_lifetime非零（若为 0，PASSWORD EXPIRE实际不生效） - 连接未使用
--init-command自动执行改密（极少见但会绕过）
最简验证方式：用该用户账号执行 mysql -u test -p 登录后立刻敲 SELECT 1;，如果报错 ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement.，才说明策略真正起效。
构建并排查Microsoft Word邮件合并及DOCX模板工作流，使用合并域、内容控件、文档属性、重复区块、数据等
password_expired 字段不是独立开关，它只是状态快照
password_expired 在 mysql.user 表里只是个只读快照字段，不能单独控制行为。它的值由以下操作联动更新：
-
ALTER USER ... PASSWORD EXPIRE→ 设为'Y' -
ALTER USER ... IDENTIFIED BY（无 EXPIRE 子句）→ 若default_password_lifetime > 0，可能设为'N'并更新password_last_changed -
ALTER USER ... PASSWORD EXPIRE NEVER→ 显式设为'N'
也就是说，这个字段本身不驱动逻辑，它只是 MySQL 内部策略计算后的结果呈现。别把它当成“开关”去手动 toggle。
生产环境改 password_expired 前必须确认的三件事
在给线上账号执行 ALTER USER ... PASSWORD EXPIRE 前，务必确认：
- 该账号是否被应用或连接池复用？长连接不会被踢出，但下次重连就会卡在
ERROR 1820 - 客户端是否支持自动执行
ALTER USER USER() IDENTIFIED BY？很多 JDBC 连接池（如 HikariCP）默认不支持，需配置connection-init-sql - 有没有漏掉主机名？
'app'@'10.0.%'和'app'@'%'是两个不同用户，改错一个就白忙
最容易被忽略的是：密码过期后，用户仍能建立 TCP 连接，也能执行 SET NAMES utf8mb4 或 SELECT @@version 这类极轻量命令，但只要碰任何 DML/DDL 就立刻中断——这种“半通不通”的状态比直接拒绝更难排查。
