最准方法是直接查mysql.user表的plugin字段，因其唯一权威标识用户实际生效的认证插件（如caching_sha2_password），不依赖版本、变量或authentication_string解析；必须用select user, host, plugin from mysql.user确保全表扫描，避免权限、host匹配或null值导致误判。
直接查 mysql.user 表的 plugin 字段，就是最准、最可靠的方法。 它不依赖 MySQL 版本号、不看配置变量、也不解析 authentication_string 里那一串乱码，只反映每个用户实际生效的认证方式。
为什么必须用 SELECT user, host, plugin FROM mysql.user
因为 plugin 是唯一权威字段：它直接对应服务器加载并使用的认证插件名，比如 caching_sha2_password 或 mysql_native_password。其他方式全是间接推测：
-
SHOW VARIABLES LIKE '%password%'只告诉你服务端是否启用了某类插件（比如 RSA 密钥路径），跟具体用户无关 -
authentication_string里存的是二进制哈希值，开头可能是$A$、$5$或一长串十六进制，但同一串内容在不同插件下解法完全不同 - 不加
FROM mysql.user就执行SELECT user, host, plugin，MySQL 默认查当前数据库，很可能报错或返回空结果
执行时要注意的几个坑
常见错误现象包括查不到数据、显示 NULL、或者只看到部分用户——基本都出在权限或语法上：
- 没用 root 或有
SELECT权限的账号登录，会提示Access denied；必须先确保能连上且有系统库读取权限 -
host值是'%'和'localhost'是两个独立账号，不能混为一谈；查所有用户就得用全表扫描，别漏掉WHERE host = 'localhost'这种限定 - 结果中
plugin列为NULL，不是“没设置”，而是该用户被禁用或状态异常，认证链已断裂，需进一步排查账户状态 - Ubuntu 包安装的 MySQL 常见
auth_socket插件，它根本不校验密码，而是靠 Unix 系统用户身份登录；这种不能直接改plugin，得先确认你是否允许用密码登录
怎么快速定位问题用户
典型使用场景是连接失败后排查兼容性问题，比如 Navicat 报 authentication plugin 'caching_sha2_password' cannot be loaded：
- 先运行
SELECT user, host, plugin FROM mysql.user;扫一遍，重点看报错用户对应的plugin值是不是caching_sha2_password - 如果只关心某个用户，务必带上完整匹配：
SELECT user, host, plugin FROM mysql.user WHERE user = 'root' AND host = 'localhost';（注意单引号和@不写在这里） - 发现混用情况（如监控账号是
mysql_native_password，但应用账号是caching_sha2_password），说明部署不统一，后续维护容易踩坑
真正容易被忽略的是：plugin 字段为空或为 auth_socket 时，你改密码、重置认证方式都无效——得先确认登录路径是否允许走密码验证，否则所有 ALTER USER 操作都是徒劳。
