下記のケースの解決策を色々探しましたが、残念ながら似たようなケースは見つかりませんでした。
次のシナリオがあります: (新しいユーザーとして、サイトは私の写真を拒否しましたが、メールで送信できます。以下はそのテキスト表現です)
Table 1 "swap_plan" Table 2 "cell"
ClusterName | SiteID SiteID | Cell | Time | Counter
----------------------- ---------------------------------------------
Cluster A | SiteID A1 SiteID A1 | Cell A1-1 | day1 | 5
Cluster A | SiteID A2 SiteID A1 | Cell A1-1 | day2 | 3
Cluster A | SiteID A3 SiteID A1 | Cell A1-1 | day3 | 6
Cluster A | SiteID A4 SiteID A1 | Cell A1-2 | day1 | 6
Cluster A | SiteID A5 SiteID A1 | Cell A1-2 | day2 | 2
Cluster A | SiteID A6 SiteID A1 | Cell A1-2 | day3 | 9
....................... ..............................................
Cluster B | ......... ..............................................
(Where No 1) (ON Clause "SiteID") (Where No 2) Sum(Counter)
いくつかのパフォーマンス インジケーター (テーブル 2 の「セル」からの「カウンター」)、経時的に集計されたもの (テーブル 2 の「セル」からの「時間」)、およびクラスター (テーブル 1 の「swap_plan」からの「ClusterName」) を表示する必要があります。
結合は、両方のテーブルの共通列「SiteID」を介して行われます。表 2 の「セル」では、各 SiteID が 3 つの異なるオブジェクト (「セル」) で構成されていることに注意してください。したがって、実際には、各セルの「カウンター」の SUM() を実行します。
クエリは次のとおりです。
SELECT ClusterName,Time,SUM(counter)
FROM cell
INNER JOIN swap_plan ON swap_plan.Siteid = cell.Siteid
WHERE ClusterName='Cluster A' AND Time>=day1 AND Time<=day2
GROUP BY Time
列の種類は次のとおりです。
表1「スワッププラン」：
- クラスタ名 - CHAR(30)
- サイト ID - VARCHAR(10)
表 2「セル」:
- サイト ID - VARCHAR(10)
- 時間 - DATETIME
- カウンター - INT
「説明」には次のように表示されました。
table type key key_len ref rows Extra
swap_plan ref Index 1 30 const 31 Using where; Using index; Using temporary; Using filesort
cell ref Index_siteid 13 swap_plan.SiteID 368 Using where
使用されるインデックスは次のとおりです。
swap_plan: インデックス 1 (1.ClusterName および 2.SiteID)
セル: Index_siteid (SiteID)
オプティマイザが参照する行数はかなり少なく、これは良いことです。
swap_plan: 6066 のうち 31、cell: 6.6 ミルのうち 368。
私の問題は、これらの「一時的な使用; ファイルソートの使用」です。私が理解している限り、これは Group By に必要な並べ替えに由来します (それを削除すると、これらのプロセスは Explain に従って実行されません)。それらを回避するには、グループ化する列にインデックスを付ける必要があることがわかりました。「Time」列のみを含む特別なインデックスがありますが、「USE INDEX FOR GROUP BY ()」というヒントがあっても、これは使用されません。
その結果、私のクエリは十分に速く実行されません。約 15 秒かかります (たとえば、15 の SiteID と 10 の日付の場合)。この時間を少なくとも半分に短縮する必要があります。
私の主な質問は次のとおりです。
- 「一時的な使用; ファイルソートの使用」を削除したり、実行に必要な時間を短縮したりすることはまったく可能ですか? (Read Buffer Size を 16MB に増やそうとしましたが、効果はありませんでした)
- JOIN の状況で必要なインデックス定義の種類、WHERE 句で異なるテーブルの 2 つの列でフィルター処理し、ON 句で 3 番目の列でフィルター処理する場合
- どの種類の Group By 最適化を適用できますか (インデックス作成など)?
事前にどうもありがとうございました！