最准的方法是直接查询mysql.user表的plugin字段，它唯一权威标识用户认证插件（如caching_sha2_password），不依赖版本、变量或authentication_string内容。
直接查 mysql.user 表的 plugin 字段是最准的
MySQL 8.0 中用户密码的加密方式完全由 plugin 字段决定，不是靠猜、不是看版本号，也不是读配置变量。只要能连上 MySQL（且有权限），执行一条 SELECT 就能拿到真实值。
-
plugin是唯一权威字段：它直接对应认证插件名，比如caching_sha2_password或mysql_native_password - 不要依赖
show variables like '%password%'：这些变量只反映服务端是否启用了某类插件（如 RSA 密钥路径），不表示某个用户实际用的是哪种 - 必须加
FROM mysql.user：该表在mysql系统库下，没USE mysql也得写全限定名，否则可能报错或查到空结果
执行 SELECT user, host, plugin FROM mysql.user 查所有用户
这条语句返回每个用户的认证方式，适合快速扫一遍有没有混用插件的情况——比如 root 是 caching_sha2_password，但监控账号却是 mysql_native_password，就容易出连接问题。
- 如果只关心特定用户，加
WHERE user = 'xxx' AND host = 'xxx'，注意host可能是'%'或'localhost'，两者权限不同，必须一起匹配 - 结果里
plugin值为空（NULL）说明该用户被禁用或状态异常，不是“没设置”，而是认证链断裂 - 某些旧迁移用户可能显示
auth_socket（常见于 Ubuntu 包安装的 MySQL），它根本不校验密码，而是依赖系统用户身份，这种不能简单改plugin，得先确认登录方式是否允许
为什么不能只看 authentication_string 内容来判断加密类型
authentication_string 存的是哈希后的二进制串（通常以 $A$、$、$ 开头，或一长串十六进制），但它本身不携带算法标识。同一个字符串，不同插件解码逻辑完全不同；反过来，不同插件也可能生成看起来相似的字符串。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
caching_sha2_password的值通常是 70+ 位十六进制，但不是绝对——开启 caching 后可能缓存未加密凭证，导致字段为空或为占位符 -
mysql_native_password的值以*A9C14...这类形式开头，但仅靠前缀识别不可靠，尤其当字段被手动更新过 - 直接
HEX(authentication_string)或LENGTH(authentication_string)辅助判断，不如老老实实看plugin字段省事又准确
SELECT plugin, COUNT(*) 统计分布时要注意权限和空值
统计每种插件用了多少用户，常用于评估迁移风险或安全审计。但这个查询容易漏掉两类人：
- 没有
SELECT权限访问mysql.user的普通账号，执行会报Access denied；必须用具备SYSTEM_USER、SUPER或显式SELECT ON mysql.user的账号运行 -
plugin为NULL的行会被GROUP BY单独归为一组，但这类用户通常无法登录，需单独排查（比如被DROP USER但残留记录） - 如果看到大量
sha256_password，要确认客户端是否支持——Java 8u181+、Connector/J 8.0.12+ 才默认兼容，老版本会静默降级失败
真正麻烦的从来不是查不到，而是查到了 plugin 是 caching_sha2_password，但应用连不上，这时得立刻检查客户端驱动版本和连接参数里有没有显式指定 allowPublicKeyRetrieval=true&useSSL=false ——这些细节比字段值本身更致命。
