- 状态
- 已解决
- 解决于
- 2.3.8
问题概述
自 WPML Media Translation 插件的 2.3.0 版本起，可以在翻译之间翻译和同步媒体。
作为设置过程的一部分（当您从早期版本迁移时也会运行），WPML Media 会扫描整个站点以查找内容中使用的媒体 URL。
标记包含媒体的文章有助于后续操作，因此，在发生与媒体翻译相关的某些事件（例如翻译特定媒体文章）时，将仅扫描实际包含媒体的文章，以便使用翻译后的媒体更新内容。
但是，对于非常大的站点，设置过程可能会对数据库造成一些压力，导致整个过程比预期更慢。
在很大程度上，这种压力是由根据 URL 识别附件 ID 所需的查询引起的。通常，可以从 HTML 标签的属性中确定附件 ID（例如 id=”attachment_8” – 此处，8 是附件的 ID）。当未使用此类属性时，WPML Media 会根据实际 URL 确定 ID。在这种情况下，会使用两种类型的查询：
- 针对 wp_posts 表中的 ‘guid’ 字段进行匹配的查询
- 针对 wp_postmeta 表的 meta_value 字段进行匹配的另一个查询。
然而，默认情况下这些表字段都没有建立索引。由于这是文本匹配（即使不是部分文本搜索），因此对于大型数据库来说可能会很慢。
临时解决方法
解决此问题的一种方法是（至少暂时）为这些字段添加索引。
您可以使用类似以下的两个 SQL 查询来执行此操作：
ALTER TABLE `wp_posts` ADD INDEX `guid` (`guid`);
ALTER TABLE `wp_postmeta` ADD INDEX `meta_value` (`meta_value`(512));
除了使磁盘上数据库的物理大小略微增加之外，这些添加操作不会对您的数据库产生任何副作用。如果您更希望在运行 WPML 媒体设置后将其回滚，可以使用以下两个 MySQL 查询来完成：
ALTER TABLE `wp_posts` DROP INDEX `guid`;
ALTER TABLE `wp_postmeta` DROP INDEX `meta_value`;
注意：根据您的 WordPress 配置，查询中提到的数据表的 wp_ 前缀可能会有所不同。通常在默认情况下，它是 wp_。
案例研究示例：在一个包含约 140,000 个附件和约 5,000 篇文章的站点上，设置可能需要 30 多分钟才能完成。添加索引后，设置只需几分钟即可运行完毕。这些测试是在常规开发环境中进行的。在实际的生产服务器上，这些数值甚至可能更理想。