mysql - 选择查询中的重复列提供更快的查询执行

Question

从 MySQL 5.6 获得一些奇怪的行为。下面的查询应该从连接中选择一些简单的数据。效果很好。

SELECT 
  f.followID, 
  l.object_id,
  l.created_at,
  ROUND(UNIX_TIMESTAMP(l.created_at)/(3600)) window
FROM fb_follow f LEFT JOIN fb_likes l ON f.followID = l.user_id
WHERE f.profileID = 1
  AND l.created_at > '20171119' LIMIT 1000;

当我错误地包含了 l.created_at 行的副本时，奇怪的事情发生了。

SELECT 
  f.followID, 
  l.object_id,
  l.created_at,
  l.created_at,
  ROUND(UNIX_TIMESTAMP(l.created_at)/(3600)) window
FROM fb_follow f LEFT JOIN fb_likes l ON f.followID = l.user_id
WHERE f.profileID = 1
  AND l.created_at > '20171119' LIMIT 1000;

查询执行时间从 ~600ms 到 ~350ms(针对不同的 f.profileID 值重复)。查询时间较短的原因是什么？我的预期是至少需要由于返回的数据较少，所以时间更短？

Answer 1

两个缓存

将 SELECT 更改为 SELECT SQL_NO_CACHE 消除了“查询缓存”的使用。

通常使用查询缓存时，查询时间在1ms或更短。 350ms 表示这不是 QC。

另一个主要缓存是 InnoDB 的 buffer_pool。 (您正在使用 InnoDB，对吗？)当您第一次运行查询时，它可能需要访问磁盘以获取索引和/或数据 block 。第二次，这些 block 可能仍然缓存在 buffer_pool(在 RAM 中)中，因此查询会更快。

差异通常是 10 倍。但也有很多异常(exception)。 600 与 350 不符合该模式，但尚无定论。

所以，当计时做两件事时:

1. 选择 SQL_NO_CACHE ...
2. 运行查询两次，并使用第二次计时。

解释

请为每个变体运行 EXPLAIN SELECT ...。如果有任何差异(我对此表示怀疑)，这可能会为“复制一条线改变时间”的原因提供新的见解。

加入

不要在不需要时使用 LEFT。它使读者感到困惑。由于您在 f.profileID = 1 上进行显式过滤，因此 LEFT 将被忽略(并且可以删除)。

订购方式

只有 LIMIT 而没有 ORDER BY 通常是愚蠢的。您想要哪 1000 行？添加 ORDER BY 将使决定明确。是的，它可能会减慢查询速度。

有用的索引

为了更好的表现:

`f` needs INDEX(followID, profileID)   -- in this order
`u` needs INDEX(created_at)