MySQL无法直接禁止用户修改自身密码，因其权限模型未提供独立开关；可行方案是锁定账户、回收ALTER USER等权限，并清理外部硬编码密码。
直接禁止用户改自己密码，MySQL 本身不支持
MySQL 没有内置机制能「禁止某用户执行 SET PASSWORD 或 ALTER USER ... IDENTIFIED BY」这类操作，只要用户有 CREATE USER、ALTER USER 或全局 UPDATE 权限（比如通过 GRANT ALL PRIVILEGES），就能改自己密码。这不是配置漏了，是设计如此——MySQL 的权限模型里，「改自己密码」默认不单独设开关。
真正可行的替代方案：锁账户 + 收权限
想让某个用户彻底无法改密，只能从两个层面动手：一是让其失去改密能力，二是让其连登录都受限，从而断掉操作入口。
-
ALTER USER 'username'@'host' ACCOUNT LOCK;—— 立即锁定账户，后续任何连接都会报错ERROR 3118 (HY000): Access denied for user 'username'@'host'. Account is locked. -
REVOKE ALTER USER, CREATE USER, INSERT, UPDATE ON mysql.* FROM 'username'@'host';—— 回收所有可能用于改密的权限（注意：不能只 revokeUSAGE，它无法被回收） - 确认没留后门：
SHOW GRANTS FOR 'username'@'host';应只剩极简权限（如仅SELECT某库某表），且不含任何涉及mysql系统库的操作权
为什么不用“改随机密码”或“清空密码”？
这两个操作看似能阻止用户继续用旧密码登录，但实际风险更大：
-
ALTER USER 'u'@'%' IDENTIFIED BY RANDOM PASSWORD;—— 密码虽变，但用户仍可正常登录（新密码会返回给客户端），之后照样能再执行一次ALTER USER改回来 - 把
authentication_string清空或设为空字符串 —— MySQL 8.0+ 会拒绝空密码；5.7 则可能允许空密码登录，反而更不安全 - 最致命的是：只要用户还保有
ALTER USER权限，以上所有“改密”动作都形同虚设
生产环境必须同步做的三件事
光在数据库里操作不够，真实场景中容易忽略配套动作：
- 检查应用配置文件（如
application.yml、.env）是否硬编码了该用户的密码——若已泄露，锁账户只是延缓，不是解决 - 确认连接池（如 HikariCP、Druid）未启用自动重连并缓存旧凭证；某些驱动在连接失败时会反复尝试，暴露错误细节
- 如果用户是程序账号（非人用），建议改用角色（
ROLE）管理：创建只读角色，授予该角色而非直接授给用户，后续权限调整只需动角色，不碰用户本身
真正卡死密码修改，靠的不是某条命令，而是权限回收 + 账户锁定 + 外部凭证清理三者缺一不可。少一步，就可能被绕过。
