如何查询MySQL 8.0用户表的plugin字段以识别用户加密方法？

本文共计1005个文字，预计阅读时间需要5分钟。

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$、$、$ 开头，或一长串十六进制），但它本身不携带算法标识。同一个字符串，不同插件解码逻辑完全不同；反过来，不同插件也可能生成看起来相似的字符串。

• 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 ——这些细节比字段值本身更致命。