0

1) 最初に使用されたクエリ ... 約 23 秒かかりました

select a.id from mza_movie_upload a,mza_movie_statics b 
where a.status=1 and b.download=1 and a.id=b.rid 
group by b.rid order by sum(b.download) desc

現在、クエリを変更しました..約9秒かかります

select a.id from mza_movie_upload a 
INNER JOIN mza_movie_statics b 
ON a.id=b.rid WHERE a.status=1 and b.download=1 
group by b.rid order by sum(b.download) desc

explain select a.id from mza_movie_upload a  INNER JOIN mza_movie_statics b  ON     a.id=b.rid WHERE a.status=1 and b.download=1  group by b.rid order by sum(b.download) desc;

+----+-------------+-------+--------+------------- --+---------+---------+----------------------+----+---- ---+------------------------------------------------ --+
| | ID | select_type | テーブル | タイプ | 可能な_キー | キー | key_len | 参照 | 行 | 行 エクストラ |
+----+-------------+-------+--------+------------- --+---------+---------+----------------------+----+---- ---+------------------------------------------------ --+
| | 1 | シンプル | b | すべて | ヌル | ヌル | ヌル | ヌル | 1603089 | where を使用します。一時的な使用; ファイルソートの使用 |
| | 1 | シンプル | | | eq_ref | プライマリ | プライマリ | 4 | mmdfurni_dev11.b.rid | 1 | where | の使用
+----+-------------+-------+--------+------------- --+---------+---------+----------------------+----+---- ---+------------------------------------------------ --+
2行セット (0.03秒)

どのようなパフォーマンスを行うべきかわかりません。このクエリを高速にしたい..ridとidのインデックスを作成しようとしましたが、それでもクエリが悪化しました。

テーブル詳細はこちら

mza_movie_upload

+------+--------------+------+-----+----- --+----------------+
| | フィールド | フィールド タイプ | ヌル | キー | キー | デフォルト | エクストラ |
+------+--------------+------+-----+----- --+----------------+
| | ID | int(11) | いいえ | PRI | ヌル | auto_increment |
| | ユーザー ID | varchar(200) | いいえ | | | ヌル | | |
| | 電子メール | varchar(200) | いいえ | | | ヌル | | |
| | 更新日 | 日時 | いいえ | | | ヌル | | |
| | ファイルサイズ | varchar(200) | いいえ | | | ヌル | | |
| | 一時ファイル名 | varchar(200) | いいえ | | | ヌル | | |
| | ファイル名 | varchar(200) | いいえ | マル | ヌル | | |
| | ファイルパス | varchar(255) | いいえ | | | ヌル | | |
| | ステータス | varchar(20) | いいえ | | | ヌル | | |
| | ip | varchar(200) | いいえ | | | ヌル | | |
| | カテゴリ | varchar(200) | いいえ | | | ヌル | | |
| | mコード | bigint(20) | いいえ | | | ヌル | | |
| | 映画名 | varchar(200) | いいえ | | | ヌル | | |
+------+--------------+------+-----+----- --+----------------+
13 行セット (0.00 秒)

mza_movie_statics

+----------+---------+------+-----+---------+---- ------------+
| | フィールド | フィールド タイプ | ヌル | キー | キー | デフォルト | エクストラ |
+----------+---------+------+-----+---------+---- ------------+
| | ID | int(11) | いいえ | PRI | ヌル | auto_increment |
| | 取り除く | int(11) | いいえ | | | ヌル | | |
| | ユーザーID | int(11) | いいえ | | | ヌル | | |
| | 保存 | int(11) | いいえ | | | ヌル | | |
| | ダウンロード | int(11) | いいえ | | | ヌル | | |
| | 入力 | 日付 | いいえ | | | ヌル | | |
+----------+---------+------+-----+---------+---- ------------+
6行セット (0.00秒)
4

3 に答える 3

0

COVERING インデックスと見なされるものがあれば、クエリをより最適化できます。つまり...インデックスには、基準を含む探しているものに関連付けられた列があります。このように、エンジンは実際にそれぞれのステータスをチェックしてパーツをダウンロードするために生データにアクセスする必要がありません。

したがって、mza_movie_upload では (id, status) にインデックスがあり、mza_movie_statics には (rid, download) にインデックスがあります。

次に、group by は、クエリを駆動しているインデックスで最適に機能します。a.id = b.rid ですが、a.id が駆動インデックスになる可能性があるため、IT を group by value とします。

select
      mu.id
   from
      mza_movie_upload mu
         JOIN mza_movie_statics ms
            on mu.id = ms.rid
           AND ms.download > 0
   group by
      b.rid
   order by
      sum( b.download ) DESC

さて、ダウンロードについてコメントします。数値のように見えるので、列が何かがダウンロードされた回数のカウンターであるように見えるので、明示的に「1」と比較したくないでしょう。そして、あなたが探しているのは、最も多くダウンロードされたものです。これが常に 1 の値である場合、はい、> 0 ではなく = 1 のままにします。

于 2013-09-30T01:15:16.427 に答える
0

さらにパフォーマンスを向上させたい場合は、a.status や b.download にインデックスを適用することをお勧めします。追加のインデックスを作成すると、レコードの挿入/更新/削除に関して追加のオーバーヘッドが発生することに注意してください。この場合、間違いなく必要と思われます。

さらに、これらのテーブルに新しいインデックスを追加する前に (おそらく本番環境で)、mysql がテーブルの一時コピーを作成することに注意してください。これには、多数のレコード (>100 万) を持つテーブルの場合、時間がかかる場合があります。（そのため、同様のサイズのテーブルでローカルにテストすることをお勧めします）

最後に、クエリの where 句に a.status=1 があることに気付きましたが、status 列は varchar です。2 つの異なるデータ型間の変換 (クエリの実行時間が遅くなる) を回避し、将来のインデックスを壊す可能性を避けるために、次のように変更することをお勧めします: a.status='1' (引用符に注意してください)

于 2013-09-29T14:08:45.450 に答える
0

クエリを次のように書き直してみてください。

SELECT b.rid 
FROM mza_movie_upload a 
INNER JOIN mza_movie_statics b 
ON a.id=b.rid 
WHERE a.status= '1'  and b.download= '1'  
-- group by b.rid order by sum(b.download) desc;
GROUP BY b.rid ORDER BY count(*) DESC;

このクエリSELECT a.idでは、 に置き換えられSELECT b.rid、述語のために元のクエリと 100% 同等ですが、JOIN ... ON a.id=b.ridMySql をわずかに優れた計画に導きます。

また、@Dennis Leona.status= '1' and b.download= '1'が提案したように、数値ではなく文字列と比較されます。

また、次のように置き換えorder by sum(b.download) descてみてくださいorder by count(*) desc- クエリは b.download = '1' の行のみを取得するため、次sum( b.download )と同等ですcount(*)- この変更により、 内の文字列から数値への変換で数百ミリ秒を節約できますSUM( .. )。

最後に、2 つのインデックスを作成します。

create index bbbb on mza_movie_statics( download, rid );
create index aaaaa on mza_movie_upload( status );

上記の変更後にクエリ速度を試してください。

于 2013-09-29T21:03:14.127 に答える