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，光写插件那行不够
插件加载本身很快，但策略变量的联动逻辑藏得深，漏掉一步，整个密码校验就形同虚设。
评论(0)