mysql中禁止用户修改他人密码的唯一有效方式是撤销alter user和create user权限，因二者均允许执行alter user语句修改任意用户密码，且直改mysql.user表被内核硬编码禁止。
ALTER USER 权限本身不区分“自己”和“他人”
MySQL 的 ALTER USER 语句没有内置的“仅限自身”限制逻辑。只要用户拥有 ALTER USER 权限，执行 ALTER USER 'other'@'host' IDENTIFIED BY 'xxx' 就合法——它不校验当前登录用户是否等于目标用户。这不是疏漏，是设计如此：权限模型只管“能不能执行这个语句”，不管“语句参数是否指向自己”。
唯一可控入口是回收 CREATE USER 权限
CREATE USER 权限隐含 ALTER USER 能力（官方文档明确说明），且能操作任意用户。而单独授予 ALTER USER 的情况极少，生产环境几乎都通过 GRANT ALL PRIVILEGES 或 CREATE USER 间接获得。所以真正要卡住“改他人密码”，只需：
REVOKE CREATE USER ON *.* FROM 'u'@'%';REVOKE ALTER USER ON *.* FROM 'u'@'%';- 确认
SHOW GRANTS FOR 'u'@'%'输出中不再出现这两项
注意：UPDATE 权限对 mysql.user 表无效——MySQL 内核硬编码拒绝直写系统表，哪怕你显式授了该权限，UPDATE mysql.user SET authentication_string=... 仍会报错 ERROR 1290 或 ERROR 1372。
但“允许改自己密码”无法单独放开
MySQL 没有 ALTER OWN USER 这类权限。一旦你回收了 ALTER USER，用户连改自己密码都不行。常见误区是以为留着 USAGE 或库级权限就能保留改密能力，其实不能：SET PASSWORD 和 ALTER USER ... IDENTIFIED BY 都依赖全局权限，不是表级或库级权限能触发的。
- 想让用户还能改自己密码？只能不回收
ALTER USER，但这就无法阻止他改别人 - 用
validate_password插件只能拦弱密码，不能区分操作对象 - 试图用代理层（如 ProxySQL）拦截含
'other'@'host'的ALTER USER语句可行，但需额外运维成本
真正落地的取舍方案
生产中没人真需要“只许改自己、不许改别人”这种精细控制。更实际的做法是分角色隔离：
- 运维人员用高权限账号（带
CREATE USER），但走堡垒机+审计日志 - 应用账号只给
USAGE+ 业务库SELECT/INSERT/UPDATE，彻底无权碰用户管理 - 如果必须让某人重置自己密码，就用临时高权限账号（有效期 1 小时），操作完立即回收
所谓“控制特定用户只能改自己”，本质是权限模型不支持的伪需求。MySQL 的边界很清晰：要么全放（ALTER USER），要么全锁（回收 + ACCOUNT LOCK）。硬要折中，最后往往变成靠流程和监控兜底，而不是靠 SQL 权限本身。
