Question

我没有多想过就写过这个问题，但作为初学者，我几乎可以肯定它可以写得更好。

这是：

    SELECT filehash, filename, filesize, group_files
      FROM files
INNER JOIN (  SELECT filehash group_id,
                     COUNT(filehash) group_files
                FROM files
            GROUP BY filehash) groups
        ON files.filehash = groups.group_id
  ORDER BY group_files DESC,
           filesize DESC

表格定义：

CREATE TABLE files (fileid INTEGER PRIMARY KEY AUTOINCREMENT,
                    filename TEXT,
                    filesize INTEGER,
                    filehash TEXT)

索引定义：

CREATE INDEX files_filehash_idx
          ON files(filehash)
CREATE UNIQUE INDEX files_filename_idx
                 ON files(filename)
CREATE INDEX files_filesize_idx
          ON files(filesize)

查询EXPLAIN QUERY PLAN：

selectid    order   from    detail
1           0       0       SCAN TABLE files USING COVERING INDEX files_filehash_idx (~1000000 rows)
0           0       1       SCAN SUBQUERY 1 AS groups (~100 rows)
0           1       0       SEARCH TABLE files USING INDEX files_filehash_idx (filehash=?) (~10 rows)
0           0       0       USE TEMP B-TREE FOR ORDER BY

如果我错了，你能纠正我吗？提前谢谢。

Answer 1

您如何看待这个版本？

  select filehash, group_concat(filename), filesize, count(*) as group_files
    from files
group by filehash
order by group_files desc

看起来这可能会跑得更快。它能满足您的需求吗？

Answer 2

不。看起来对我来说。

我认为您不需要此查询的文件名索引。有计划文件大小的索引会有所帮助，但MySQL没有使用它们。在（filehash，filesize）上使用复合索引替换两个单独的索引可能会更好。或者你可能不会！

更好的查询策略，按文件散列频率和文件大小对文件进行排序

2 个答案: