更好的查詢策略，通過文件哈希頻率和文件大小對文件進行排序

我已經寫了這個查詢沒有太多想法，但作爲一個初學者，我幾乎肯定它可以寫得更好。更好的查詢策略，通過文件哈希頻率和文件大小對文件進行排序

這就是：

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)

查詢說明查詢計劃：

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

如果我錯了，你能糾正我嗎？先謝謝你。

來源

2011-03-05 Paulo Freitas

您對這個版本有什麼看法？

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

看來這樣可能會跑得更快。它是否滿足您的需求？

來源

2011-03-15 06:00:58

我不知道SQLite也支持'group_concat'函數。很高興知道！我會試試這個，然後回來說它是否工作得更好。謝謝！ :) – 2011-03-20 00:30:29

它工作更好嗎？ – 2011-04-10 06:10:34

對不起，錯過了這個...這個查詢明顯改善了搜索時間，現在比以前快了96％！再次感謝你！ :) – 2012-07-27 17:33:59

沒有。看着我。

我不認爲你需要此查詢的文件名索引。有計劃索引文件大小會有所幫助，但MySQL沒有使用它們。用（filehash，filesize）上的複合索引替換兩個單獨的索引可能會更好。或者你可能不會！

來源

2011-03-05 22:58:51

更好的查詢策略，通過文件哈希頻率和文件大小對文件進行排序

回答

相關問題