MySQL 8.0.19+ 才真正支持 password_history，低于该版本无此变量；需同时满足版本≥8.0.19、插件为 caching_sha2_password、全局或用户级显式设置 password_history 和 password_reuse_interval 均非零，且密码修改必须通过 ALTER USER ... IDENTIFIED BY 触发，否则策略不生效。
MySQL 8.0.19+ 才真正支持 password_history，低于这个版本设了也白设，连变量都不存在。
确认版本和插件是否达标
不查版本就配参数，大概率在兜圈子。先连上 MySQL 执行：
SELECT VERSION();
输出必须是 8.0.19 或更高。再检查目标用户的认证插件：
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';
结果中 plugin 必须是 caching_sha2_password（MySQL 8 默认）或 sha256_password。mysql_native_password 完全不支持该策略，设了也不报错，但绝不生效。
- 若插件不对，先改插件：
ALTER USER 'your_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'xxx'; - 改完别忘了
FLUSH PRIVILEGES;，否则新插件不加载 - 客户端（如旧版 Navicat、某些脚本）若不支持 SHA2 协议，
ALTER USER会报Plugin caching_sha2_password could not be loaded
全局设置 vs 用户级设置，哪个才管用
SET PERSIST password_history = 5; 只影响后续新建的用户；对已有用户完全无效。很多运维踩坑就在这里——改了全局变量，再进 phpMyAdmin 点“改密码”，旧密码照样能复用。
- 真正起效的是用户级声明：
ALTER USER 'u1'@'%' PASSWORD HISTORY 5; - 必须显式写
PASSWORD HISTORY，只写IDENTIFIED BY不触发校验 - phpMyAdmin 图形界面改密码底层调用的是
SET PASSWORD，它绕过所有历史检查，所以禁用该入口更安全 - 想让所有现有用户都受控？得逐个执行
ALTER USER ... PASSWORD HISTORY N;，没有批量命令
为什么设了 password_history 还是没拦住旧密码
最常见原因是没配 password_reuse_interval。MySQL 要求这两个参数**同时非零**，策略才激活。比如只设 password_history = 5，而 password_reuse_interval 仍是默认的 0，那整个策略等同于关闭。
- 推荐组合：
SET PERSIST password_history = 5;+SET PERSIST password_reuse_interval = 90; -
password_reuse_interval = 0表示“不限制时间”，此时password_history形同虚设 - 错误
ERROR 3638 (HY000): Cannot use these credentials...出现，恰恰说明策略正在工作 - 手动
UPDATE mysql.user改authentication_string，或用--skip-grant-tables启动后改密，都不会写入mysql.password_history表
验证是否真生效，别只看变量值
查 SELECT @@global.password_history; 返回 5，不代表用户改密时就被拦。必须实测：
- 用命令行执行：
ALTER USER 'u1'@'%' IDENTIFIED BY 'old_password_used_2_times_ago'; - 如果返回
ERROR 3638，说明历史记录已存且校验通路畅通 - 查历史表确认记录存在：
SELECT * FROM mysql.password_history WHERE User = 'u1';（需有 SELECT 权限） - 注意：该表只存哈希，无法反推明文，也不能直接删记录；“清理历史”只能靠多次改密覆盖，或临时设
PASSWORD HISTORY 0
真正的难点不在配置，而在确保每次密码变更都走 MySQL 认可的路径——只有 ALTER USER ... IDENTIFIED BY 和符合上下文的 SET PASSWORD（当前用户）才会触发写入与校验，其他任何绕过方式都会让策略失效。
