“分组依据”的替代方法以避免低性能速度？答案

【问题标题】：Alternative way to "group by" to avoid low performance speed?“分组依据”的替代方法以避免低性能速度？
【发布时间】：2017-06-19 13:21:29
【问题描述】：

我想按b.hash 分组，但是这样做成本太高。有什么方法可以进行此查询，但也可以使用 group by 但更快？

SELECT STRAIGHT_JOIN b.hash, b.page, n.favorite
FROM behaviour b, new_table n
WHERE b.timestamp >= NOW( ) - INTERVAL 20 SECOND 
AND b.hash = n.hash

这是EXPLAIN

PROFILING

【问题讨论】：

好吧，可悲的是没有。您正在发送 560 万行。这是一个相当大的数据块。首先，您需要发送它，接收端也需要缓冲它以接收它。解决方案是发送更少的数据。您需要发回 560 万行吗？
当涉及到分析器输出时，MySQL 中实际上存在一个小错误。它显示从 previous 步骤所花费的时间。这意味着它执行了大约 7 秒。现在，原因 - 因为要找到记录然后减少它们，它必须检查 560 万行。现在我们回到“它必须找到磁盘上的记录”的故事，这部分很慢，因为磁盘很慢。发生这种情况时，我们知道 I/O 有问题，我们想将 I/O 转移到 RAM，这就是著名的 innodb_buffer_pool_size 变量发挥作用的地方。有时您只需检查所有数据。
总有一点你可以编写 SQL - 在我们的工作中，你的代码 / SQL 的好坏是有限度的。如果您达到了这个限制，如果您编写了一段出色的代码或 SQL，但它仍然很慢，那么就是这样 - 您要么希望获得更好的硬件，要么尝试将工作分散到更多机器上（如果可能的）。如果不是这样，你就会屈服于对可能发生的事情和需要做的事情的物理限制。在你的情况下 - 如果可能的话，我会通过增加 innodb_buffer_pool_size 将 I/O 转移到 RAM。
我认为 straight_join 比分组更可能是您的问题。 stackoverflow.com/questions/512294/…
嗯，这有点问题，MyISAM 虽然在当时非常出色，但遗憾的是对于今天的服务器和用户来说有点过时了。恐怕我不能用 MyISAM 帮助你做到这一点，但是I'd suggest you give this question a read

标签： php mysql indexing query-performance

【解决方案1】：

我猜你想要这个查询

SELECT b.hash, b.page, n.favorite
  FROM behaviour b
  JOIN new_table n ON b.hash = n.hash
 WHERE b.timestamp >= NOW( ) - INTERVAL 20 SECOND 
   AND b.hash = n.hash
 ORDER BY b.hash

我不明白您在问题中对GROUP BY 的评论。您似乎想要最近 1/3 分钟的项目。

无论如何，如果您在包含以下列的behaviour 表上创建复合索引，您的查询可能会以可接受的速度开始运行。

 (timestamp, hash, page)

为什么？ MySQL 的查询计划器可以随机访问索引以从查询中的 timestamp 值开始。那是 O(log n) 快。然后它可以按顺序扫描索引以获取查询所需的信息。这几乎是瞬间完成的。

你想要这个吗？

SELECT b.hash, b.page, MAX(n.favorite)
  FROM behaviour b
  JOIN new_table n ON b.hash = n.hash
 WHERE b.timestamp >= NOW( ) - INTERVAL 20 SECOND 
   AND b.hash = n.hash
 GROUP BY b.hash, b.page

还是这个？

SELECT b.hash, b.page, GROUP_CONCAT(n.favorite)
  FROM ...

【讨论】：

【解决方案2】：

请为两张表提供SHOW CREATE TABLE。同时，我猜……

b 没有以timestamp 开头的索引，但它需要这样。

像往常一样，Profiling 是“无用的”——99% 的指示时间都花在了模糊的“发送数据”上。

【讨论】：