ここで私の前の質問にフォローアップとして:Linkこのクエリは30秒で実行されます。どのように私はそれを最適化できますか?
はこれらが私のテーブルです:
-----------------------------------
ID | ChapterNo | HitCount | MID
-----------------------------------
1 | 2 | 1000 | 1
2 | 2 | 2000 | 1
3 | 1 | 3000 | 1
4 | 3 | 1000 | 1
5 | 1 | 3500 | 1
-----------------------------------
結果をアーカイブするために、私はFFのクエリを使用してみました:
SELECT t1.id, t1.hitcount, t1.chapterno
FROM chapter as t1
WHERE t1.hitcount = (select max(hitcount) from chapter where chapterno = t1.chapterno and `mid` = t1.`mid`)
AND t1.`mid` = '2524'
ORDER BY t1.chapterno DESC
ID | ChapterNo | HitCount |
---------------------------
4 | 3 | 1000 |
2 | 2 | 2000 |
5 | 1 | 3500 |
---------------------------
このクエリは、テストと実装のために80,000レコードをインポートした後は、最初は本当にうまく動作しているようですが、規模は大きくなります。私はこれが30秒間実行されたことを知ります。説明は次のとおりです。
sel_type table type posible_key key keyLen ref rows Extra
PRIMARY t1 ref mid_idx mid_idx 8 const *3289* Using where; Using filesort
PRIMARY chapter ref mid_idx mid_idx 8 m.t1.mid *17* Using where; Using temporary; Using filesort
結果セットは640行です。大きなテーブルでこれを最適化する本当に良い方法はありますか?このテーブルと特にこのクエリは将来的にさらに成長するでしょう。
このクエリでは、mysqlのプロシージャを使用すると便利ですか?
は、これらのフィールドのすべての3つに
私がここで行うのは、YESです... MID、ChapterNoおよびHitCountのインデックス...次にJOINコマンドで 'MID = 2524'を修飾します。他のすべてに基づいて結合しようとする理由内部クエリから修飾されない可能性のある「中間」値。これは、両方の部品が中間、章、ヒットカウントを使用するので、クエリに対して完全に最適化された状態を維持します。 – DRapp
クエリを変更してグループを追加すると、このクエリは4秒間実行されました。かなり大きな改善と私は同じ結果を得た。そして、私はこれを前にしてChapternoとhitcountにインデックスを追加しました。結果は0.1秒で実行されました! – DucDigital
追加:元のクエリは、MID、Chapternoおよびhitcountのインデックスを使用して1.4秒で実行されました。 – DucDigital