ORDER BY COUNT 很慢

Question

一个表 ( phototag ) 由两个外键列 ( photoid , tagid ) 组成。 我想根据标签获取最相关的照片。

有 400 万张带有 5-10 个标签的照片。 例如，photoid 10009有 6 个标签。 我需要具有相似标签的照片。

SELECT photoid
FROM phototag
WHERE photoid != 10009
  AND tagid IN (21192, 3501, 35286, 21269, 16369, 48136)
GROUP BY photoid
ORDER BY COUNT(photoid) DESC
LIMIT 24;

如果没有ORDER BY COUNT ，查询速度会非常快。

我试过但没有结果：

• 优化表
• 基于两列制作主键
• 单独索引列
• 将 InnoDB 切换到 MyISAM

更新

这是带有explain前缀的结果

Answer 1

众所周知，计数查询难以优化。 但是，我们应该能够索引WHERE子句。 考虑尝试以下复合索引：

CREATE INDEX idx ON phototag (photoid, tagid);

该索引涵盖WHERE子句以及SELECT ，并且在与GROUP BY聚合时应该可用。

另一种完全不同的方法是创建一个汇总表。 该表将采用以下结构：

photoid | count
10000   | 25
10001   | 300
...     | ...

每次您向phototag中插入一条新记录时，它不是列入黑名单的tagid值之一，您也会更新汇总表。 例如，假设您刚刚为photoid 10001 插入了白名单标签，您将执行以下更新：

UPDATE summary
SET count = count + 1
WHERE photoid = 10000;

现在，有了这个汇总表，您的原始查询就变成了：

SELECT photoid
FROM summary
WHERE photoid != 10009
ORDER BY count DESC
LIMIT 24;

请注意，不需要聚合。 相反，聚合一直在汇总表中发生。

Answer 2

如果没有ORDER BY子句，如果数据库找到24条满足条件的记录，可能会在读取所有表记录之前返回结果。 使用 ORDER BY 子句，数据库必须读取所有记录，以便根据计数结果对它们进行排序。

IN 运算符使查询难以优化。 数据库需要重复访问索引的次数与变量的数量一样多。 在这些情况下，计划生成器很容易被诱导进行表扫描。

我认为创建索引没有帮助。 但是phototag(tagid, photoid)比phototag(photoid, tagid)好，因为当条件为负时数据库不能使用索引。

Answer 3

如果你改变你所说的“相似”的意思，你可以减少数据库引擎需要做的工作量。 （主要是，避免对全部或大部分 400 万张照片的“分数”进行排序。

例如，您可以选择共享目标照片的一个“最稀有”标签的所有照片。

SELECT *
  FROM phototag
 WHERE photoid != 10009
   AND tagid = (
         SELECT tagid
           FROM phototag
          WHERE tagid IN (
                  SELECT tagid
                    FROM phototag
                   WHERE photoid = 10009
                )
       GROUP BY tagid
       ORDER BY COUNT(*), tagid
          LIMIT 1
       )

在(tagid, photoid)和(photoid, tagid)上都有索引。

这大大减少了需要处理的行数并使处理更容易。

但...

这不是您最初要求的，它可能会返回零匹配照片。

这是什么...

“相似”的不同定义示例，可以减少正在处理的数据量，从而加快查询速度。

所以，这是你的权衡...

任何一个：

• 您接受读取和重新排序几乎整个表的查询的缓慢性能
• 您将“相似”重新定义为“更容易解决”但可能“不太好”的东西

Answer 4

汇总表最好（参见汇总表）。 但是，没有这样的：

SELECT photoid
    FROM phototag
    WHERE photoid != 10009
      AND tag IN ('this', 'that, ...)
    GROUP BY photoid
    ORDER BY COUNT(*) DESC
    LIMIT 24;

和

CREATE TABLE phototag (
    photoid INT UNSIGNED NOT NULL,
    tag VARCHAR(99),
    PRIMARY KEY(photoid, tag),
    INDEX(tag, photoid)
) ENGINE=InnoDB

注意：不要包含 id； 使用复合索引。

我发现将标记作为字符串而不是 id 可以简化编码并可能加快执行速度——而不是首先必须找到 tagids。 这样想：一个INT是 4 个字节，但是AVG(LENGTH(tag))是什么？ 可能不会超过 4 个。

考虑FULLTEXT ：

如果在照片表（或平行表）中，您有一个tags TEXT列和FULLTEXT(tags) ，那么这可能会工作得更快：

SELECT photoid
    FROM photos
    WHERE    MATCH(tags) AGAINST("this that ...")
    ORDER BY MATCH(tags) AGAINST("this that ...") DESC
    HAVING photoid != 10009
    LIMIT 24;

（注意最小标记长度和停用词。）

（使用IN BOOLEAN MODE和/或NATURAL LANGUAGE可能会更好。）