确认插件残留数据库表名需进入phpMyAdmin查看左侧表列表，或执行SHOW TABLES LIKE 'wp\_%'筛查，再比对已卸载插件名称及文档；重点核查表是否被wp_options中选项引用、是否存在外键约束，并确保备份后按“禁用外键→删表→清选项→恢复外键”三步安全清理。
怎么确认插件残留的数据库表名？
卸载插件后，它创建的自定义表不会自动删除。这类表通常带明显命名特征：以 wp_ 开头，中间含插件名缩写或功能关键词，比如 wp_wpforms_entries、wp_elementor_library、wp_sucuri_scanner_log。别只靠猜——进 phpMyAdmin 左侧表列表滚动查找，或执行这句快速筛查：
SHOW TABLES LIKE 'wp\_%';
然后人工比对：哪些表名你没在当前启用插件文档里见过？哪些对应已删除插件？重点留意那些长期没被查询、数据量小但存在多年的表。
为什么不能直接 DROP TABLE wp_xxx？
- 某些表虽是插件建的，但可能被其他插件或主题间接引用（比如共享日志结构）；
- 表里若有外键约束（尤其在 MySQL 5.7+ InnoDB 中），
DROP TABLE 可能报错或级联删错东西；
- 更隐蔽的风险：有些插件把配置存进
wp_options，却用表名当标识符；删表不删选项，下次重装会报“表已存在”冲突。
DROP TABLE 可能报错或级联删错东西；wp_options，却用表名当标识符；删表不删选项，下次重装会报“表已存在”冲突。所以必须先查依赖再动手。执行这个语句看有没有活跃引用：
SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%wp_xxx%';
把 wp_xxx 替换成你怀疑的表名。如果返回结果含 JSON 或序列化数组，说明还有逻辑关联，别急着删。
立即学习“PHP免费学习笔记（深入）”；
安全删除残留表的三步操作
-
备份整库：phpMyAdmin 顶部选“导出”，格式选
Custom，勾选 ADD DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT，下载到本地；
-
禁用外键检查（临时）：在 SQL 标签页执行
SET FOREIGN_KEY_CHECKS = 0;
，避免因约束中断删除；
-
逐个删表 + 清理选项：对每个确认无用的表，分两步执行：
DROP TABLE IF EXISTS `wp_xxx`;
DELETE FROM wp_options WHERE option_name LIKE 'wp_xxx\_%' OR option_name = 'wp_xxx';
Custom，勾选 ADD DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT，下载到本地；SET FOREIGN_KEY_CHECKS = 0;，避免因约束中断删除；
DROP TABLE IF EXISTS `wp_xxx`;
DELETE FROM wp_options WHERE option_name LIKE 'wp_xxx\_%' OR option_name = 'wp_xxx';
删完立刻执行
SET FOREIGN_KEY_CHECKS = 1;恢复约束保护。
删完还要验证什么？
- 检查 WordPress 后台是否报错（尤其是“数据库错误”或“未知表”提示）；
- 查
wp_options 里是否还剩插件前缀的选项，比如 widget<em>myplugin</em>*、myplugin_settings；
- 运行一次
OPTIMIZE TABLE wp_options, wp_posts, wp_postmeta;
—— 删表本身不释放磁盘空间，OPTIMIZE 才真正回收碎片。
wp_options 里是否还剩插件前缀的选项，比如 widget<em>myplugin</em>*、myplugin_settings；OPTIMIZE TABLE wp_options, wp_posts, wp_postmeta;—— 删表本身不释放磁盘空间，
OPTIMIZE 才真正回收碎片。最常被忽略的是：有些插件残留表其实存着用户提交的数据（如表单记录），删前务必确认这些数据是否已导出归档。没备份就删，恢复成本远高于清理收益。
