MySQL报错MY-010732插件卸载后还在占用资源，远程帮忙修复问题

开始）

客户打电话过来,语气很着急，说他的MySQL数据库服务器出问题了，日志里不停地刷一个错误，错误代码是MY-010732，错误信息大概说的是，有一个插件明明已经卸载了，但是系统显示它还在运行，并且占用着资源，客户自己尝试重启过MySQL服务，但问题依旧，重启后那个错误信息又出现了，他担心这样下去会影响数据库的性能和稳定性，所以请求远程协助，赶紧帮他解决掉。

我首先让客户把完整的错误日志片段发给我看,日志里清晰地写着：[2024-05-21 10:23:45] [MY-010732] [Server] Plugin 'example_plugin' is disabled but still loaded. 这行字很关键，它直接指出了矛盾点：一个名叫'example_plugin'的插件已经被禁用了，可它的代码还留在内存里，没有被清理掉，这就好比你把一个软件从电脑上卸载了，但它的后台进程还在偷偷运行，不仅占着CPU和内存，还可能引发一些莫名其妙的问题。

我问他这个'example_plugin'是什么插件，客户说这是他之前为了测试某个功能而安装的一个第三方插件，后来觉得用不上就把它停掉了，我告诉他，这个问题在MySQL中不算特别罕见，尤其是在动态安装和卸载插件的情况下，根本原因通常是，插件在卸载时，可能因为某些依赖关系或者卸载过程中的小故障，没有完全从服务器的内存中释放干净，虽然通过INSTALL PLUGIN和UNINSTALL PLUGIN命令在逻辑上完成了操作，但物理上插件的共享库文件（.so文件）可能还被系统抓着不放。

为了确认当前的状态,我让客户在MySQL命令行里执行一个查询：SELECT * FROM INFORMATION_SCHEMA.PLUGINS; 让他找找看还有没有名字叫'example_plugin'的记录，客户查完后说，果然没有这条记录了，这说明从MySQL的系统表来看，这个插件确实已经被成功卸载了，这就印证了错误日志的说法——“已禁用”（在系统表里不存在了），但“仍加载着”（在内存里没清掉）。

既然逻辑上已经卸载,但物理上还残留，那么最直接有效的办法就是让MySQL进程彻底重启一次，强制释放所有占用的内存资源，客户说他试过用服务管理器重启MySQL服务，但没效果，我告诉他，服务管理器的“重启”命令，在某些系统配置下，可能只是一种“温和”的重启，不一定能完全杀死所有相关的进程并清空内存，我们需要做一次更彻底的“冷重启”。

我指导他完成了以下步骤：让他用有权限的账户连接到MySQL，执行SHOW PROCESSLIST; 命令，确认没有重要的业务查询正在运行，并通知可能受影响的用户，让他使用系统的服务管理命令，比如在Linux上用的是systemctl stop mysql命令，先把MySQL服务完全停止掉，停止之后，不能马上启动，我让他再用ps aux | grep mysql命令检查一下，看看是否还有任何挂着“mysql”字样的进程在运行，他检查后说，确实还有一个旧的mysqld进程没有退出，这就是问题的关键所在了！那个陈旧的进程仍然加载着那个已经被卸载的插件，所以每次新的MySQL进程启动时，检测到这种不一致，就会在日志里报告MY-010732错误。

我让他使用kill命令,后面跟上那个残留进程的PID（进程号），强制结束它，他操作完后，确认所有MySQL相关的进程都已经被终止了，我让他再次使用systemctl start mysql命令，重新启动MySQL服务，服务启动后，他等了一两分钟，然后去查看最新的错误日志，他高兴地告诉我，那个烦人的MY-010732错误信息再也没有出现了，为了进一步验证，我让他再次运行了几个简单的数据库查询，确认数据库功能一切正常，问题已经彻底解决。

我跟客户总结了一下,告诉他这个问题就像是电脑用久了需要彻底关机再开，而不是仅仅睡眠一下，以后如果再遇到类似卸载插件后感觉资源没释放干净的情况，可以尝试这种完整的停止服务、检查并清理残留进程、再重启服务的方法，也提醒他，对于非必要的第三方插件，如果确定不再使用，卸载是最好的选择，但卸载后如果遇到奇怪问题，就要想到可能是这种“幽灵”加载状态在作祟，客户表示理解，并对远程支持表示感谢。 结束）