問題タブ [explain]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
mysql - 複雑な結合のMYSQL EXPLAIN出力を解読するのに助けが必要です
私のサイトのホームページには、次のような複雑なクエリがあります。
正確な詳細については説明しませんが、簡単に説明します。基本的に、これはシステム内で発生したイベントのリストであり、ストリームのようなものです。イベントにはいくつかのタイプがあり、そのタイプに基づいて、さまざまなテーブルから特定のデータを結合する必要があります。
現在、このクエリの実行には 2 秒かかりますが、エントリの量が増えるにつれて時間の経過とともに遅くなります。したがって、私はそれを最適化しようとしています。MYSQL Explain の出力は次のとおりです。
EXPLAIN についての私の理解は、これを理解するにはあまりにも限られています。このクエリを (非正規化するのではなく) そのままにしておくことをお勧めしますが、適切なインデックスまたはその他のクイック ウィンを使用してパフォーマンスを向上させます。この説明の出力に基づいて、フォローアップできるものはありますか?
編集:ここで要求されたように、カルマログテーブルの定義:
sql - Postgres SQL Explain 削除ステートメント
質問。この postgres からの戻り値EXPLAIN DELETE FROM ...
:
コスト 19474 は、秒単位の実行時間を意味しますか? 19474s = 5.4時間のように?
ありがとう!
mysql - 単純な MySQL インデックス作成の問題
私はこのテーブルを持っています:
このテーブルに 10 000 000 行を入力します。日付による再分割は均一です
これが結果です
=> 説明なしで 3.6 秒 (約) 3000 行の結果
ご覧のとおり、インデックスは使用されておらず、possible_keys 列の一部ではありません!
カバリング インデックス ウェイを使用した同じリクエスト
結果:
=> 説明なしで 3000 行の結果に対して 2.8 秒 (約)
MySQL がこのインデックス (DATE) を適切に使用しないのはなぜですか ???
情報: - VM サーバー (私たちの開発環境、ハードウェア構成はわかりません) - MySQL 5.5.8
結果:
- 日付 2014-03-04 => 3134 行
- 合計 (ロールアップ) => 7 875 488
- テーブルには 2556 個の異なる「日付」値があります
mysql - 場合によっては MySQL の「一時的な使用」を避ける
私は2つのテーブルを持っていusers
ますfollowers
:
表users
:
id
このテーブルはおよびで索引付けされていjoined
ます。
テーブル「フォロワー」:
users
このテーブルはおよびで索引付けされていfollows
ます。
このクエリは、特定の時間後に参加した特定のユーザーが後に続くすべてのユーザーの名前を検索します。結果は時系列の逆順にする必要があります。
ここで、ユーザー X に多数のフォロワーがいる場合、EXPLAIN は次のようになります。
ここまでは順調ですね。('using where' は、簡潔にするために削除した他のいくつかの句によるものです)。
しかし、ユーザー X のフォロワー数が少ない場合は、次のようになります。
を省略するとORDER BY
、次のようになります。
MySQL オプティマイザーは、処理する必要がある行数を調べているようで、少ない場合は
followers
最初にテーブルを処理します。最適化ステップでを無視しているようORDER BY
で、一時テーブルが原因でクエリが遅くなります。
だから(最後に)、私の質問は次のとおりusing temporary
です。
mysql - MySQLの説明出力
誰かが違いを知っていますか
インデックスの使用
と
whereを使用する; インデックスの使用
mysqlのexplain出力(Extra)で?
再生:
mysql> Explain select count(1)from tmp_t1 where a = 1 \ G
mysql> Explain select count(1)from tmp_t1 where b ='b1' \ G
最初のケースでは追加フィールドに「インデックスの使用」しかなく、2番目のケースでは「どこで使用;インデックスを使用」である理由を誰かが知っていますか?ケースの違いは、最初のケースは整数でWHEREを実行し、2番目のケースはvarchar(50)フィールドで実行されることです。しかし、なぜそれが重要なのですか?
ご協力いただきありがとうございます!
mysql - MySQL の「Explain」にダミーの値を設定するにはどうすればよいですか?
たとえば、これは私のコードです。このクエリを MySQL で説明したいのですが、story_id を配置する値がありません。ダミーIDで説明するにはどうすればよいですか?たとえば、story_id が「9」であるかのように、MySQL に Explain ステートメントを提供してもらいたいとします。
基本的に、story_id または user_id が提供されていなくても、MySQL にこのクエリを説明してもらいたいだけです。
mysql - MySQL。「OR」クエリのインデックスを作成する
INT の列を持つ 200k エントリのテーブルがあります。クエリを高速化するためにインデックスを作成したいと考えています。これは実行したいクエリです: SELECT A,B,C,D,E FROM table WHERE A=23 and (B=45 or C=43)
. 次のインデックスを作成しました: B
、ACD
、。C
ABC
コマンドを使用するEXPLAIN
と、MySQL が index を選択することがわかりましたACD
。そのため、テーブルにさらに多くの値を入力し続けたところ、MySQL が上記のインデックスを切り替えていることに気付きました (常に同じであるとは限りません)。
多くの挿入があるため、さまざまなインデックスを持つとパフォーマンスの問題が発生し、このテーブルは、すべてのインデックスが意味を持つ異なる列を必要とする他のクエリによってアクセスされると想定できます。
については承知してUSE INDEX()
いますが、MySQL を信頼して正しいインデックスを選択する必要があるかどうかを理解したいと思います。
mysql - 結合を使用してMySQLクエリを最適化するためのヘルプが必要
MySQLの説明を読み、理解し、最適化する方法を理解するのにまだ問題があります。orderby列にインデックスを作成することは知っていますが、それだけです。したがって、このクエリの調整にご協力いただければ幸いです。
このクエリが行うことは、種のカルマが最も多い写真を見つけることです。このライブの結果を見ることができます:
http://www.jungledragon.com/species
画像ごとに複数の画像ファイル(フォーマット)があるため、種のテーブル、画像のテーブル、その間のマッピングテーブル、および画像ファイルテーブルがあります。
出力の説明:
種のテーブルについては、プライマリIDとフィールドcommonnameにインデックスがあります。画像テーブルについては、idフィールドとkarmaフィールドにインデックスがあり、他にもこの質問に関係のないものがいくつかあります。
このクエリは現在0.8から1.1秒かかりますが、私の意見では遅すぎます。正しいインデックスがこれを何度もスピードアップするのではないかと疑っていますが、どれがどれかわかりません。
mysql - MySQL スロー クエリ: 記事をカウントし、カテゴリ別にグループ化し、最適化する方法はありますか?
このクエリを最適化する方法はありますか? 2.5秒以上かかります。
すでにキャッシングを使っているので、コード的には問題ありません。
これは SQL の説明の結果です。
ありがとう。
mysql - MySQL を複数のインデックスから読み取らせますか?
簡単な例から始めましょう。
したがって、2 つの列で、両方ともインデックスが作成されます。これは、すべてのデータがインデックスに格納されているため、MySQL が実際のテーブルを読み取る必要がなくなることを意味していると思いました。
「インデックスの使用」、とてもいいです。私の理解では、これは、実際のテーブルからではなく、インデックスからデータを読み取っていることを意味します。しかし、私が本当に欲しいのは「値」列です。
うーん、今回は「インデックスを使用」はありません。
両方の列をカバーするインデックスを追加すると役立つと思いました。
ここで、前の選択ステートメントをもう一度実行して、新しいインデックスを使用するように指示しましょう。
主をたたえよ、それは索引から読んでいる。
しかし、実際には、他の目的のために複合インデックスは必要ありません。MySQL を 2 つの別々のインデックスから読み取らせることは可能ですか?
どんな洞察も大歓迎です。
編集:わかりました、さらに別の例です。これは、元のテーブル定義 (つまり、各列のインデックス) を使用したものです。
これは確かに両方のインデックスから読み取る必要があります (結合条件で両方のフィールドが使用されるため) が、それでも実際のレコードからデータを読み取りますよね? インデックスから読み取ったデータを使用しないのはなぜですか? それとも、「インデックスを使用する」とは言わずに、実際にそのデータを使用しますか?
再度、感謝します