【发布时间】:2018-08-14 18:45:08
【问题描述】:
对于报告输出,我曾经删除并重新创建表“mis.pr_approval_time”。但现在我只是截断它。
用数据填充上表后,我运行了一个 UPDATE 语句,但我已将其写为下面的 SELECT...
SELECT t.account_id FROM mis.hj_approval_survey h INNER JOIN mis.pr_approval_time t ON h.country = t.country AND t.scheduled_at =
(
SELECT MAX(scheduled_at) FROM mis.pr_approval_time
WHERE country = h.country
AND scheduled_at <= h.created_at
AND TIME_TO_SEC(TIMEDIFF(h.created_at, scheduled_at)) < 91
);
当我运行上述语句甚至只是......
SELECT t.account_id FROM mis.hj_approval_survey h INNER JOIN mis.pr_approval_time t ON h.country = t.country AND t.scheduled_at =
(
SELECT MAX(scheduled_at) FROM mis.pr_approval_time
WHERE country = h.country
);
...它永远运行,似乎没有完成。 hj_approval_survey 表中只有约 3,400 行,pr_approval_time 中只有 29,000 行。我在具有 15+ GB RAM 的 Amazon AWS 实例上运行它。
现在,如果我只是右键单击 pr_approval_time 表并选择 ALTER TABLE 选项,然后不做任何事情直接关闭,那么上述查询将在几秒钟内运行。
我想当我触发 ALTER TABLE 选项并且 Workbench 填充表字段时,它可能会以某种方式改进其执行计划,但我不知道为什么。有没有人遇到过类似的情况?如何在不右键单击表并选择“ALTER TABLE”的情况下触发更好的执行计划检查
编辑
值得一提的是,我的组织也使用 DOMO。最初,我在 DOMO 上将此设置作为 MySQL 数据流,但在大多数情况下查询不会完成,但我观察到它有时会完成。
这就是我将此查询移回我们的 AWS MySQL RDS 的原因。所以这个问题不仅在我们自己的 MySQL RDS 上观察到,而且可能在 DOMO 上也观察到了
【问题讨论】:
-
您是否索引了 WHERE 子句中涉及的列?这将是最简单的性能调优步骤。
-
@Littlefoot 是的,两个表都创建了索引列并显示在查询计划(解释)中。当我在那里看到它时,它显示为绿色框,但查询没有完成。此外,正如我在上面提到的,即使没有索引列,30,000 行也算不了什么
标签: mysql sql mysql-workbench sql-execution-plan