MySQL如何处理同名用户不同Host的权限问题

SELECT USER() 和 CURRENT_USER() 不一致说明登录声明身份与权限校验所用账号不同，MySQL 严格按 'user'@'host' 组合匹配，未精确匹配时会退选通配符规则，可能导致权限误配或安全隐患。

SELECT USER() 和 CURRENT_USER() 返回值不一致说明什么

这说明你登录时声称的身份（USER()）和 MySQL 实际匹配并用于权限检查的账号（CURRENT_USER()）不是同一个。MySQL 不是按用户名查权限，而是严格匹配 'user'@'host' 这个组合。如果 USER() 是 'app'@'192.168.1.100'，但 CURRENT_USER() 是 'app'@'%'，就代表没有精确匹配的账号，退而使用通配符规则——此时哪怕你连的是内网固定 IP，也可能被套上最宽松（也最危险）的权限配置。

MySQL 怎么选中同名但不同 Host 的用户

MySQL 按 host 字段的“精确度”排序后取第一行，不是随机也不是合并。精确度排序规则是：

1. 字面 IP 地址（如 '192.168.1.100'）最优先
2. 带子网通配的 IP（如 '192.168.1.%'）次之
3. '%' 排在后面，空字符串更靠后
4. DNS 主机名（如 'web01.example.com'）不自动解析，必须和 mysql.user.Host 字段**完全一致**才匹配

例如你有 'app'@'192.168.1.100' 和 'app'@'%'，哪怕客户端密码只对后者正确，MySQL 也会先尝试用前者认证——失败就直接报错，根本不会 fallback 到后者。

GRANT 时漏写 Host 会默认变成 % 吗

不会。MySQL 的 GRANT 语句必须显式指定 Host，否则报语法错误。常见误操作是复制了旧命令但删掉了 @'host' 部分，结果执行的是 GRANT ... TO 'user';，这会触发 MySQL 报错：ERROR 1227 (42000): Access denied; you need (at least one of) the CREATE USER privilege(s) for this operation。真正容易踩坑的是 CREATE USER：不写 host 时默认为 '%'，但 GRANT 不接受省略。

删除多余同名用户时为什么还要 DROP USER 而不只是 REVOKE

REVOKE 只清权限，不删账号；DROP USER 才真正从 mysql.user 表里移除记录。如果你只 REVOKE ALL PRIVILEGES 却没 DROP USER，那个 'app'@'old-host' 仍留在系统里——下次有人从 old-host 连入，MySQL 还是会匹配它（哪怕权限为空），然后因无任何权限而报 Access denied，排查时极难定位。

安全做法是：先确认该账号确实不再使用（比如查 processlist 或审计日志），再执行 DROP USER 'user'@'host';。注意，不能只删 mysql.user 表里的行，必须用 DROP USER，否则残留的权限元数据可能引发一致性问题。