匿名用户导致“access denied”是因为权限校验短路：匹配到''@'localhost'等空user记录后，因select_priv='n'直接拒绝，不查db表；current_user()返回空用户名即可确认劫持；需查user、db、tables_priv、proxies_priv等表清理残留；mysql 5.6用delete+flush，5.7+用drop user；docker初始化、错误grant、含匿名用户的备份恢复均可能使其复活。
为什么匿名用户会导致“Access denied”却查不到权限问题
因为 MySQL 权限校验是短路的：user 表匹配成功后，只要某权限字段（如 Select_priv）值为 'N'，就直接拒绝，根本不会继续查 db 表里的同名用户授权。而匿名用户（User = ''）常被创建成 ''@'localhost' 或 ''@'127.0.0.1'，它们的 Select_priv、Insert_priv 等默认是 'N'，但 Host 匹配优先级又极高——你用 mysql -u app -h 127.0.0.1 登录时，MySQL 可能先匹配到 ''@'127.0.0.1' 这条记录，于是直接返回拒绝，哪怕 'app'@'127.0.0.1' 其实有完整权限。
- 执行
SELECT USER(), CURRENT_USER();，如果两者不一致（比如USER()是'app'@'127.0.0.1'，而CURRENT_USER()是''@'127.0.0.1'），基本可断定是匿名用户劫持了认证 -
CURRENT_USER()返回空用户名，就是最直接的信号 - 别只看
SHOW GRANTS FOR 'app'@'127.0.0.1'，它不反映实际生效的账号
如何一次性查全所有匿名用户残留权限
删掉 ''@'localhost' 只清了入口，mysql.db、mysql.tables_priv、mysql.proxies_priv 里还可能挂着空用户名的权限，删不干净照样生效。
- 必须连查四张表：
SELECT * FROM mysql.user WHERE User = ''; SELECT * FROM mysql.db WHERE User = ''; SELECT * FROM mysql.tables_priv WHERE User = ''; SELECT * FROM mysql.proxies_priv WHERE Proxied_user = '';
-
mysql.columns_priv和mysql.procs_priv也建议扫一遍，尤其当应用报错涉及列操作或存储过程时 - 注意 IPv6 地址：
''@'::1'和''@'localhost'是两条独立记录，漏掉一个就留后门
MySQL 5.6 和 5.7+ 删除匿名用户的写法差异
硬套统一命令会失败。5.6 不支持 DROP USER ''@'host'，强行执行报 ERROR 1396 (HY000): Operation DROP USER failed；5.7+ 用 DELETE 则可能残留权限未清理。
- MySQL 5.7 及以上：
DROP USER ''@'localhost'; DROP USER ''@'127.0.0.1'; DROP USER ''@'::1'; - MySQL 5.6 或更早：
DELETE FROM mysql.user WHERE User = '';，之后**必须**执行FLUSH PRIVILEGES; - 删完立刻验证：
SELECT User, Host FROM mysql.user WHERE User = '';结果应为空
匿名用户“复活”的三个高发场景
不是删一次就永久安全。以下操作会无声无息重建空用户名，且不会触发任何告警。
- Docker 初始化时用了未设密码的
mysqld --initialize（某些旧版镜像默认行为） - 误写授权语句：
GRANT SELECT ON mydb.* TO '@localhost';（引号内为空）或CREATE USER '@%'; - 从含匿名用户的备份恢复：
mysqldump --all-databases默认导出mysql库，mysql.user里的''@'xxx'会被原样还原
真正关键的不是“怎么删”，而是把 SELECT User, Host FROM mysql.user WHERE User = ''; 塞进巡检脚本——每周自动跑，结果非空就钉钉告警。IPv6、备份恢复、容器重部署这些环节，人盯不住，只能靠机器卡口。
