0

所以我一直在努力运行这个查询。这需要很长时间。
它的 MySQL Innodb。我正在使用的字段已编入索引。它在一个相当强大的服务器上,大约 10gig 分配给了 innodb 池配置。

UPDATE TEMP_account_product p
JOIN products_temp c ON (c.`some_id` = p.`old_someid`)
SET p.`product` = c.id
WHERE p.product IS NULL;

这里要注意的是,两个表都包含大约 900,000 行。这条线带回了大约 800,000 条记录 ( WHERE p.product IS NULL;)

我有一种感觉,我在这里有点搞砸了,但我还是想试试。

4

2 回答 2

0

我建议分批运行它,这样您就不需要依赖查询计划来决定在它开始执行更新之前不将整个结果集放入内存。在查询中添加类似 LIMIT 1000 的内容,然后运行它直到受影响的行数为零(技术取决于您的环境,但我认为可以在 SQL 中完成)。

更新,这不是一个有效的选项(原样)

果然,我在更新文档中忽略了这一点:

对于多表语法... 在这种情况下,不能使用 ORDER BY 和 LIMIT。

于 2012-08-10T14:37:16.237 回答
0

我认为此类请求执行缓慢的可能原因可能是:

  • 最有可能- 您在更新字段上有一个 INDEX(es),并且该请求正在更新很多行 - 在这种情况下,MySQL 将需要在 UPDATE 期间做大量工作来重建该 INDEX(es)。在这种情况下,只需在请求之前 DROP INDEX(es),然后重新创建它(如果需要)。
  • JOIN 很慢(您可以通过使用该 JOIN 进行选择来检查它) - 即连接是在没有索引的情况下完成的。在这种情况下添加索引。
  • WHERE 的慢速过滤(即 MySQL 对过滤器进行全面扫描) - 您可以通过使用相同的过滤器进行选择来检查它的速度。
于 2012-08-10T14:49:41.897 回答