SELECT USER(), CURRENT_USER()结果不一致是因为USER()返回客户端声明的身份，CURRENT_USER()返回MySQL实际匹配并用于权限校验的user@host条目；两者不同说明Host字段未精确匹配，触发通配符降级或socket协议强制识别为localhost。
为什么SELECT USER(), CURRENT_USER()结果不一致？
这不是bug，而是MySQL权限匹配逻辑的直接体现。USER()返回你“声称”的身份（客户端传来的host），CURRENT_USER()才是实际匹配并用于权限校验的user@host条目。两者不同，说明Host字段没对上。
常见现象：
-
USER()是'app'@'192.168.5.23'，但CURRENT_USER()是'app'@'localhost'——说明你用了mysql -uapp -p（无-h），MySQL强制走socket协议，只认localhost，哪怕你从远程IP连过来 -
USER()是'app'@'DESKTOP-ABC123'，CURRENT_USER()是'app'@'%'——说明MySQL没找到精确主机名匹配，退而使用通配符
如何看清楚mysql.user表里Host的真实排序？
别信字典序：ORDER BY host ASC会把'%'排在'localhost'前面，但这和MySQL内部匹配顺序相反。它实际按“越具体越靠前”排序，等价于：
SELECT host, user FROM mysql.user ORDER BY LENGTH(host) DESC, host DESC;
这样能近似还原真实匹配优先级。关键排序规则是：
- 精确值优先：
'localhost'、'127.0.0.1'、'192.168.1.100' - 然后是模糊匹配：
'192.168.1.%'、'%.example.com' -
'%'排最后；空字符串''比'%'还靠后 - 同Host下，非空
user优先于空user（匿名用户）
为什么删掉'foo'@'localhost'反而连不上？
MySQL要求至少一个高权限账户（如root或等效）能通过localhost登录，否则服务启动后可能无法管理。直接DROP USER 'foo'@'localhost'没问题，但如果你只剩这一行且它被用来做本地维护入口，删完就真进不去了。
更安全的做法：
- 保留
'foo'@'localhost'，同步密码哈希：UPDATE mysql.user SET authentication_string=(SELECT authentication_string FROM mysql.user WHERE user='foo' AND host='%') WHERE user='foo' AND host='localhost'; FLUSH PRIVILEGES; - 若已锁死，用
mysqld --skip-grant-tables启动跳过认证，再修复 - 永远别删掉
'root'@'localhost'——除非你确认有其他root账户能从%或127.0.0.1登录
GRANT之后权限仍不生效，是不是漏了FLUSH PRIVILEGES？
不是所有情况都需要。用GRANT或CREATE USER语句创建/修改用户时，MySQL会自动刷新内存中的权限缓存，FLUSH PRIVILEGES可省略。但它对以下场景必须执行：
- 直接
UPDATE mysql.user或INSERT INTO mysql.db等手动改系统表 - 用
mysql_upgrade升级后 - 怀疑权限缓存未更新（比如旧连接复用导致行为滞后）
注意：FLUSH PRIVILEGES本身不解决Host匹配问题——它只刷新缓存，不改变排序逻辑。如果'foo'@'localhost'始终排在'foo'@'%'前面，刷多少次都没用。
