MySQL插件加载需确认plugin_dir路径一致、文件名及权限正确、错误日志无报错、插件状态与变量启用匹配：先查SELECT @@plugin_dir;，再验证文件存在、权限、架构，最后查error.log和information_schema.PLUGINS。
查 plugin_dir 实际路径和当前值是否一致
MySQL 启动时只认 plugin_dir 配置指向的目录，不是“默认位置”或“常见路径”。很多人改了配置文件却没重启 mysqld，或者在多个配置文件（/etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf）里写冲突了，导致实际生效的 plugin_dir 和你以为的不一样。
- 连上 MySQL 执行
SELECT @@plugin_dir;，这是唯一可信的运行时路径 - 用
mysqld --verbose --help | grep plugin-dir看启动时解析出的默认值（未显式配置时才参考） - 检查
my.cnf中是否有plugin_dir项，确认它不在被注释掉的块里，且没有被后续配置覆盖
确认插件文件存在且命名符合平台规范
MySQL 插件不是扔进目录就行——文件名必须带后缀，且后缀因系统而异：.so（Linux）、.dll（Windows）、.dylib（macOS）。少一个字母、多一个空格、大小写错（比如 semisync_master.so 写成 semisync_master.SO），加载就静默失败。
- 进入
@@plugin_dir目录，用ls -l确认插件文件真实存在、可读 - 检查文件权限：MySQL 进程用户（如
mysql）必须有读+执行权限（chmod 755 xxx.so是安全的起点） - 用
file xxx.so确认是对应架构的动态库（例如 x86_64，不是 aarch64 或编译目标不匹配）
加载时看错误日志，别只信 INSTALL PLUGIN 返回 OK
INSTALL PLUGIN 成功只代表语句语法通过、注册表写入完成，不代表动态库真加载进内存。真正报错藏在错误日志里，而且往往只有 warning 级别，容易被忽略。
- 执行
INSTALL PLUGIN semisync_master SONAME 'semisync_master.so';后，立刻查 MySQL 错误日志（路径由log_error变量决定，通常是/var/log/mysql/error.log或/var/lib/mysql/hostname.err） - 搜索关键词：
Plugin、dlopen、undefined symbol、cannot open shared object file - 常见假成功现象：插件依赖另一个未安装的插件（如
semisync_master依赖semisync_slave），此时日志会提示symbol lookup error，但 SQL 不报错
验证插件状态不能只看 SHOW PLUGINS
SHOW PLUGINS 显示 ACTIVE 状态，只说明 MySQL 认为它已加载；但有些插件（尤其是半同步类）需要额外参数启用，否则只是“挂载了，没干活”。更麻烦的是，某些插件加载失败后仍残留在表中，状态卡在 DISABLED 或空着，但错误日志早已滚动过去。
- 执行
SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'semisync_master';，重点看PLUGIN_STATUS和PLUGIN_LIBRARY列是否非空 - 对半同步插件，还要查变量：
SHOW VARIABLES LIKE 'rpl_semi%';，如果全为OFF或空值，大概率没真正跑起来 - 用
lsof -p $(pgrep mysqld) | grep semisync（Linux）确认进程是否真把 so 文件 mmap 进内存，这是最硬的证据
插件加载失败最常卡在路径、权限、依赖符号三处，日志不翻到底，光看 SQL 返回结果等于没查。
