ファイルに関する情報を含む非常に大きなテーブル (8 GB) があり、それに対して次のようなレポートを実行する必要があります。
(select * from fs_walk_scan where file_path like '\\\\server1\\groot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server1\\hroot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server1\\iroot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server2\\froot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server2\\groot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server3\\hroot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server4\\iroot$\\%' order by file_size desc limit 0,30)
UNION ALL
(select * from fs_walk_scan where file_path like '\\\\server5\\iroot$\\%' order by file_size desc limit 0,30)
[...]
order by substring_index(file_path,'\\',4), file_size desc
このメソッドは、私がする必要があることを達成します: 各ボリュームの最大 30 個のファイルのリストを取得します。ただし、これは非常に遅く、別のテーブルに座っている場合でも、「いいね」検索はハードコーディングされており、その方法で取得できます。
私が探しているのは、巨大なテーブルを何度も通過せずにこれを行う方法です。誰にもアイデアはありますか?
ありがとう。
PS巨大なソーステーブルの構造を変更することはできません。
更新: file_path と file_size にはインデックスがありますが、これらのサブ (?) クエリのそれぞれにはまだ約 10 分かかり、最低 22 回実行する必要があります。