应执行SELECT User, Host FROM mysql.user WHERE User = '';若返回任意行（如''@'localhost'）即存在匿名用户，属已落地风险，需进一步排查mysql.db、mysql.tables_priv、mysql.proxies_priv中User或Proxied_user为空的残留记录。
怎么一眼确认 MySQL 里有没有匿名用户
直接连上 MySQL（用 root 或有 SELECT ON mysql.* 权限的账号），执行：SELECT User, Host FROM mysql.user WHERE User = '';
只要返回任意一行（比如 ''@'localhost'、''@'127.0.0.1'、''@'::1'），就说明存在匿名用户——这不是预警，是已落地的风险。
注意：user() 和 CURRENT_USER() 返回的是当前连接身份，完全不能代替这张表的查询；User = ' '（带空格）不算，只有纯空字符串 '' 才算。
为什么删了 mysql.user 里的空用户还不够
MySQL 的权限是分层存储的，DROP USER ''@'localhost' 只清掉主账户和关联的全局权限，但以下三处残留仍可能让空用户名继续生效：
-
mysql.db表中User = ''的记录：常见于对test库的ALL PRIVILEGES，删用户后仍能建大表占满磁盘 -
mysql.tables_priv或mysql.columns_priv中User = ''的细粒度授权：可能允许绕过应用层直接读敏感字段 -
mysql.proxies_priv中Proxied_user = ''：意味着任意用户可代理登录，变相绕过认证
所以完整排查语句至少要跑这三条：SELECT * FROM mysql.db WHERE User = '';SELECT * FROM mysql.tables_priv WHERE User = '';SELECT * FROM mysql.proxies_priv WHERE Proxied_user = '';
哪些操作会让匿名用户“死灰复燃”
不是删一次就万事大吉。这些场景会悄悄重建空用户名：
- 用未设密码的
mysqld --initialize初始化实例（某些旧版 Docker 镜像默认行为） - 手误执行
CREATE USER '@localhost';（漏写用户名）或GRANT SELECT ON *.* TO '@%';（引号内为空） - 运行
mysql_secure_installation时跳过 “Remove anonymous users?” 提示 - 从含匿名用户的备份恢复数据（
mysqldump --all-databases默认导出mysql库）
最常被忽略的是初始化环节——很多自动化部署脚本没加 --init-file 或等效 SQL 清理步骤，上线即带后门。
验证是否真清零，不能只看表
删完必须做两件事，缺一不可：
- 查表确认：
SELECT User, Host FROM mysql.user WHERE User = '';必须返回空集 - 实连测试：
mysql -u "" -h 127.0.0.1 -e "SELECT CURRENT_USER();"和mysql -u "" -h ::1 -e "SELECT CURRENT_USER();"都应报错拒绝连接
IPv6 的 ::1 和 socket 登录路径最容易被漏测；FLUSH PRIVILEGES 没执行，内存缓存未更新，实连仍可能成功——这个步骤在脚本里常被遗忘，导致“删了却还能登”的假象。
