同库多套WordPress可能以不同表前缀区分，但不能仅看名字相似就判定某组表是废弃数据。应从站点实际配置、数据库连接和插件自定义表关系反查，特别区分多站点网络与多个独立安装。
先确认当前连接和配置来源
记录目标站点实际使用的数据库主机、库名及table_prefix等配置，秘密值保持受控。面板显示的数据库名称不一定是当前进程真正使用的配置。测试站复制后也可能仍指向正式库，应先确认再执行任何查表或导入操作。
识别独立安装与多站点网络
多站点网络可能共享用户等全局表，并为子站使用特定编号前缀，不能把每一组都当完全独立。几套独立站的插件也可能创建非标准命名表。根据配置和网络结构理解关系，不用一条“不是当前前缀就删除”的规则清理数据库。
将插件自定义表纳入依赖
订单、日志、搜索索引或表单条目可能不在WordPress核心表里。查看实际插件代码、文档和运行查询，判断表用途及是否被其他站点使用。停用插件、表名陈旧或最近没写入，都不能单独证明数据不再需要。
以只读验证和映射表结束确认
先核对当前站点的公开地址、站点选项和几条已知内容，建立站点到表组的映射。若后续要清理或迁移，再单独安排可恢复备份与授权变更。不要在识别阶段试改siteurl或删除表来验证猜测，避免破坏仍运行的正式站。
关键区别
表前缀：帮助区分表组；不是可删除的唯一证据。
多站点网络：可能共享部分表；不能按子站随意拆删。
插件表：存放额外业务数据；需查实际依赖关系。
怎样确认处理到位
每套运行站点与其核心和自定义表关系明确，正式与测试环境没有误连，确认过程未改动业务数据。
容易误判的边界
识别表组不等于获得删除授权；未知前缀和旧表应保留待核实，不能把清理结果凭表名补猜。
