查插件是否加载成功应查information_schema.plugins表，重点关注plugin_status和plugin_library字段；状态为disabled且plugin_library非空表示已注册未启用，查不到则可能未安装或名称错误。
mysql插件怎么查有没有加载成功
直接查 information_schema.PLUGINS 表最靠谱，别信 SHOW PLUGINS 的默认输出——它只显示状态为 ACTIVE 的，而有些插件（比如 validate_password）可能处于 DISABLED 或 DISABLED_BY_DEFAULT，但其实已注册进内核。
实操建议：
- 用
SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'your_plugin_name';精准定位，重点看PLUGIN_STATUS和PLUGIN_LIBRARY字段 - 如果
PLUGIN_STATUS是DISABLED且PLUGIN_LIBRARY非空，说明插件文件存在、已注册，只是没启用 - 若整行查不到，大概率是插件没安装（
.so文件不在plugin_dir下），或名字拼错了（注意大小写，Linux 下敏感）
mysql插件怎么手动启用（不重启）
能不用重启就别动 my.cnf，尤其在线上库。MySQL 支持运行时加载，但有两个硬前提：插件必须是动态可加载类型（不是 builtin），且用户有 SYSTEM_VARIABLES_ADMIN + CLONE_ADMIN（8.0.17+）或旧版的 SUPER 权限。
实操建议：
- 先确认插件库文件名，比如
validate_password.so，然后执行INSTALL PLUGIN validate_password SONAME 'validate_password.so'; - 如果报错
Plugin 'xxx' is disabled，说明它被disabled_storage_engines或启动参数禁用了，得改配置并重启 -
UNINSTALL PLUGIN不会删文件，只是卸载；再INSTALL时仍走原路径，所以别手动删.so
为什么 plugin_dir 路径对了还是找不到插件
MySQL 启动时会把 plugin_dir 值固化进内存，后续 INSTALL PLUGIN 只认这个路径下的文件，哪怕你用绝对路径指定也不行。
常见错误现象：
- 明明把
semisync_master.so放到了/usr/lib/mysql/plugin/，却提示Can't open shared library '/path/to/xxx.so' (errno: 2) - 用
SELECT @@plugin_dir;发现值是/usr/lib64/mysql/plugin/—— 这才是 MySQL 实际认的目录
实操建议：
- 永远用
SELECT @@plugin_dir;查真实路径，别依赖配置文件或常识 - 确保
.so文件权限是mysql:mysql且可读（chmod 644），SELinux 开启时还要chcon -t mysqld_plugin_t - 不同发行版路径差异大：CentOS 7 默认是
/usr/lib64/mysql/plugin/，Ubuntu 20.04 是/usr/lib/mysql/plugin/
validate_password 插件启用后密码策略不生效
这是最常踩的坑：插件装上了，但 validate_password.length 这类变量压根没加载，因为插件启用了，变量没初始化。
原因很简单——MySQL 8.0+ 把这类策略变量从插件逻辑里抽出来了，变成独立的系统变量，必须显式设置。
实操建议：
- 启用插件后立刻执行：
SET GLOBAL validate_password.policy = MEDIUM;，否则默认是LOW（只校验长度） -
validate_password.length等变量是只读的，除非先设policy，否则设了也无效 - 如果想持久化，必须写进
my.cnf的[mysqld]段：validate_password.policy = MEDIUM，光写插件那行不够
插件加载本身很快，但策略变量的联动逻辑藏得深，漏掉一步，整个密码校验就形同虚设。
