SELECT @@plugin_dir 返回的路径是唯一可信值，需手动验证文件存在、权限可读可执行、后缀架构匹配，并查错误日志确认动态库是否真加载，而非仅信 INSTALL PLUGIN 成功返回。
SELECT @@plugin_dir 返回的路径才是唯一可信值
MySQL 启动时只认 plugin_dir 配置项最终生效的那个路径，不是你猜的 /usr/lib/mysql/plugin、/usr/local/mysql/lib/plugin 或文档里写的“默认位置”。多个配置文件（/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf）可能互相覆盖，注释没清理干净也会让某行失效。
连上 MySQL 后第一件事就是执行：
SELECT @@plugin_dir;这是运行时真实路径，其他全作参考。如果返回空或明显不合理（比如
/tmp/plugin/），说明配置根本没生效。
- 用
mysqld --verbose --help | grep plugin-dir看启动解析出的默认值（仅当没显式配置时才有效） - 检查所有 my.cnf 文件中
plugin_dir是否被注释、拼错、或被后面同名项覆盖 - 确认 mysqld 进程启动时确实加载了你改的那个配置文件（
ps aux | grep mysqld看启动命令带的--defaults-file）
插件文件必须存在且权限可读可执行
即使 SELECT @@plugin_dir 显示路径正确，也得进系统目录里亲手验证文件是否存在、名字对不对、权限够不够。MySQL 插件不是“放进去就自动认”，它对文件名大小写、后缀、架构都敏感。
- Linux 下必须是
.so后缀，比如auth_test_plugin.so；写成auth_test_plugin.SO或漏掉.so就静默失败 - 执行
ls -l <plugin_dir>/auth_test_plugin.so</plugin_dir>，确保 MySQL 进程用户（通常是mysql）有读和执行权限（chmod 755是安全起点） - 用
file auth_test_plugin.so检查是否为当前 CPU 架构（如x86_64），aarch64 编译的库在 x86_64 机器上加载会失败，且错误日志里往往只报 warning
INSTALL PLUGIN 成功 ≠ 插件真加载了
INSTALL PLUGIN mysql_native_password SONAME 'auth_test_plugin.so' 返回 Query OK，只代表语句通过、元数据写进了 mysql.plugins 表，不代表动态库被 dlopen 进内存。真正加载失败的线索藏在错误日志里，而且经常是 warning 级别，容易被跳过。
- 查
error.log（路径由log_error变量决定，不一定是/var/log/mysql/error.log） - 搜索关键词：
Could not open required shared library、cannot open shared object file、undefined symbol - 注意时间戳——必须对应你执行
INSTALL PLUGIN或重启 mysqld 的时刻
mysql_native_password 插件本身可能根本不在磁盘上
MySQL 8.0+ 安装包默认不附带 mysql_native_password.so 文件，它已作为内置认证逻辑硬编码进服务端，不再以独立插件形式存在。所以你搜遍 plugin_dir 都找不到这个文件，INSTALL PLUGIN ... SONAME 'mysql_native_password.so' 必然失败。
这时正确的做法不是找文件，而是确认该插件是否已注册并启用：
- 执行
SHOW PLUGINS;，看Name列是否有mysql_native_password，Status是否为ACTIVE - 如果没有，说明你的 MySQL 实例初始化时跳过了它（常见于某些 Linux 发行版精简包或自定义编译）
- 此时应优先考虑改用户认证方式（
ALTER USER ... IDENTIFIED WITH mysql_native_password），而不是强行安装插件
最常被忽略的一点：插件加载失败未必是路径或权限问题，更可能是你试图加载一个本就不该以独立文件存在的插件——比如 mysql_native_password 在现代 MySQL 中压根没有对应的 .so 文件。
