👐🏽 🌕 ☃️ MySQLのインデックス作成の基本とEXPLAIN機能 🤗 🏩 ☺️

Vasily Lukyanchikovによるレポートのトピックは、MySQLでのインデックス作成とEXPLAINの高度な機能です。私たちの仕事は、質問に答えることです。EXPLAINで何を見つけることができますか、何に注意を払うべきですか？

EXPLAINの制限の多くはオプティマイザーに関連しているので、事前にアーキテクチャを調べて、制限がどこから来て、原則としてEXPLAINで何ができるかを理解します。

一般的な理論とは対照的に、MySQLのニュアンスについてのみインデックスを簡単に説明します。

したがって、レポートは3つの部分で構成されます。

アーキテクチャ;
インデックス作成の基本
EXPLAIN（例）。

ヴァシリー・ルカンチコフ（スタニゴスト）

MySQLアーキテクチャ

概略的に、サーバーは次のように表すことができます。

最初のブロックは、通常、TCP / IPまたはUNIXソケットを介して、対応するコネクタまたはC APIの機能を介してサーバーにアクセスするクライアントです。接続制御ユニットに到達します。実際には、クライアントはこの時点で承認され、承認および実行プロセスが開始されます。各クライアントは、独自の独立したフローで動作します。追加のスレッドはサーバーによってキャッシュされ、使用されます。

クエリキャッシュについては、すべてのクライアントに共通の1つのスレッドで表されることに注意する必要があります。マルチコアアーキテクチャと非常に単純なデータベースクエリがある場合は、ボトルネックになる可能性があります。データベースはそれらを迅速に実行します。キャッシュにアクセスする時間がボトルネックになる可能性があります。これが唯一のスレッドであり、誰もがそのために並んでいるためです。

接続管理を使用すると、要求は、パーサー、オプティマイザー、エグゼキューターの3つの部分で構成されるメインパイプラインに到達します。実際、この部分は受信したSQLクエリをデータ選択に変換します。この部分は、それぞれのタスクに従って、ストレージインターフェイスと通信します。

パーサーは、要求の構文をチェックし、テーブルデータとフィールドの可用性についてストアを照会し、これらのフィールドへのアクセス権を直接照会し、クエリキャッシュ内の応答を確認してから、解析された要求をオプティマイザーに渡します。
オプティマイザーは、ストレージインターフェイスでインデックス統計を要求し、それに基づいてエグゼキューターに渡すクエリプランを作成します。
受信した計画に従って、請負業者はリポジトリ内のデータに直接適用し、インターフェイスを介してクライアントに応答を送信し、必要に応じて更新キャッシュを変更します（結果自体または更新の要求があった場合はゼロ）。

ここでは、MySQLに関連する重要な機能に注意する必要があります。これは接続されたストレージインターフェイスです。会社で独自のストレージ（標準インターフェイス）を開発して接続できます。したがって、さまざまなニュアンスを考慮して、データを最も便利な方法で保存できます。

逆の機能は、オプティマイザーがリポジトリと非常に弱く接続されており、このリポジトリまたはそのリポジトリによるリクエストの一部の実行の個々のニュアンスを認識せず、考慮しないことです。さらに、これは奇妙なことですが、MySQL開発者によって直接開発されたメインリポジトリでもひどく起こります。この状況は最新バージョンでのみ改善され始めました。この点を考慮する必要があります。

また、MySQLのインデックスはストレージレベルで正確に実装され、標準化されていないことにも注意してください。したがって、どのタイプのインデックス（フルテキスト、Bツリー、空間など）が1つまたは別のストアで使用されているかを監視する必要があります。そして最も重要なこと：異なるリポジトリの同じインデックス-それは完全に異なる構造である可能性があります。たとえば、MyISAMのBツリーインデックスにはデータ自体へのポインターが格納され、InnoDBにはプライマリキーへのポインターが格納されます。 MyISAMはプレフィックスインデックスを圧縮しますが、InnoDBは圧縮しませんが、データとインデックスの両方をキャッシュします。

作業中に考慮する必要がある多くのニュアンスがあります。あるストレージでの実行が高速なリクエストもあれば、別のストレージでのリクエストも高速です。統計の保存方法は異なります。たとえば、MyISAMの場合のリクエストカウント（*）は、データ自体にアクセスせずに非常に迅速に実行できます。統計はメタデータに保存されます。これは特別な場合に当てはまりますが、それでもそのようなニュアンスがあります。

クエリプランについて言うだけです。オプティマイザーが実行します。これは何らかの実行可能コードではなく、エグゼキューターに渡す一連の命令です。これは、リクエストの実行方法に関する提案です。エグゼキューターがリクエストを行った後、いくつかの違いが現れる場合があり、PostgreSQLとは異なり、MySQLは何が行われたかを表示しません。つまり、MySQLでEXPLAINを見ると、ANALYZEがありません。より正確には、最近ベータ版であり、もちろんまだ使用されていないMariaのバージョン10.1に登場しました。したがって、MySQLでEXPLAINを見るとき、これらはいくつかの仮定であることに注意してください。

多くの場合、同じ計画であるがパフォーマンスが異なるような状況があります。ここで、EXPLAINの観点からオプティマイザ自体が提供するものはほとんどないことに注意してください。たとえば、テーブルからクエリを選択し（*）、テーブルからフィールドのペアを選択すると同じプランになりますが、1つのケースでは各レコードに数KBを選択し、もう1つのケースでは巨大なレコードがある場合は数MBになることがあります。当然、これらのリクエストのパフォーマンスは桁違いに異なりますが、計画ではこれが示されません。または、同じプラン、1つのクエリがありますが、異なるマシンで異なる方法で実行されます。ある場合にはインデックスがメモリから読み取られ、別の場合にはバッファが小さい場合、インデックスはディスクから取得されるためです。繰り返しますが、同じ計画でもパフォーマンスは異なります。そのため、EXPLAINに加えて、まずサーバーパラメータ（show status）でさまざまなことを調べる必要があります。

ここで過去のRIT ++会議を参照するのが適切です。そこでは、MySQLの植物決定要因に関するGrigory Rubtsovの報告がありました。そこに。古典的な植物の決定要因のように、植物の定義を検索するとき、彼らは葉の数、形などに注目しました。そして答えに来ました。そのような構造があります-一貫して見える場所、ボトルネックを見つけるために何をすべきか。

MySQLのインデックスに移りましょう

すべてのタイプのインデックスを考慮してリストすることはしません-各データベースのインデックスは多かれ少なかれ標準です。 MySQLについて言えば、次の点に注意する必要があります。MySQLは、重複したインデックスを管理しません。提示されたようにテーブルを作成する場合、列1に一意のプライマリインデックスを作成することを意味しません。これは、1つの列に3つの同一のインデックスを作成することを意味します。 3つすべてがスペースを占有し、更新され、オプティマイザーによって考慮されます。MySQL自体は警告を発行しません。自分で見る必要があります。

インデックスについては（基本的には、bツリーを最もよく使用します）、詳細に入らないように、またツリーを描画しないように、アルファベット順のインデックスの形式でインデックスを表すのが非常に便利です。たとえば、アドレス帳はテーブルであり、アドレス帳へのインデックスはインデックスです。この類推を使用して、インデックスがどのように機能するかを想像できます。データがより速く選択されるなどです。しかし、MySQL自体には若干の違いがあります。MySQLは常にインデックスに沿って進むため、これにより疑問が生じる場合があります。

たとえば、アルファベット順のインデックスでいくつかの名前を見つける必要がある場合。「手」では、次のように検索します。最初の姓を見て、必要な名前を見つけ、次の姓までスクロールします。これは、bツリーツリーの制限ではなく、MySQLでのbツリーツリーの実装の制限です。他のデータベースはこれを行うことができます-たとえば、WHERE B = 3の場合、最初の列ではなく使用するため、一般にMySQLでインデックスは使用されません。特定の場合にのみ、この列から最小値と最大値を要求しますが、これはむしろ例外です。

上記のスライドでは、さまざまなオプションが提示されていますが、最初の不等式でインデックスが途切れることに注意してください。最初の不等式まで左から右に順番に使用されます。不等式の後、インデックスのそれ以降の部分は使用されなくなります。つまり条件Aでは定数、Bは範囲、最初の2つの部分が使用されます。 2番目の場合、インデックス全体が使用されます。 3番目のケースでは、インデックスも完全に使用されます。条件内の定数の順序は重要ではなく、サーバーはそれらを再配置できます。 B = 3の場合、一般にインデックスは使用されません。定数および不等式の場合、インデックスは最初の2つの部分にのみ使用され、インデックスは3番目の部分に使用できません。ケースA-定数で、最後でソートすると、最初の部分でのみインデックスが使用されます。2番目の部分がスキップされるため、最後から2番目のインデックスが完全に使用されます。また、後者のバージョンでは、インデックスは最初の部分にのみ使用されます。これは、インデックスをソートするために使用できるのは一方向に限られているためです。

これは、MySQLの複合インデックスは、実際には、それぞれ着信列の連結に対する通常のbツリーインデックスであり、タプル全体の昇順または降順で移動できるためです。したがって、「Bの増加とCの減少に動いている」と言うことはできません。これはMySQL固有の制限です。

そのようなニュアンスがあります。たとえば、（0,1）のAと0と1の間のAは同等の形式であり、これはあちらこちらの範囲ですが、この（0,1）のAがリストの場合、そうではないと理解します範囲、および等式の複数条件を置き換えます。この場合、インデックスを使用します。これは、MySQLのもう1つのニュアンスです。リストまたは<>を使用して、記述方法を監視する必要があります。彼はそれを区別します。

冗長構文についてのいくつかの言葉。インデックス（A）とインデックス（A、B）があれば、インデックス（A、B）の場合はパートAを使用できるため、インデックス（A）は不要です。したがって、冗長なインデックスがないことを確認し、自分で削除する必要があります。明らかに、これは両方のインデックスがbツリーである場合にも当てはまりますが、たとえばインデックス（A）がフルテキストの場合、もちろん必要な場合があります。

リストのニュアンスに戻りましょう。ここで、より広いインデックスを一意にすることができます。たとえば、インデックス（A、B）を作成する場合、単純に条件Bを使用しませんが、可能性のある小さなリストオプションがある場合は、不足している条件を独自に置き換えるようにアプリケーションで作成できます。しかし、この推奨事項では、リストが存在する場合、インデックスのさらなる使用が破棄されないという事実にもかかわらず、ソートに使用できないため、非常に注意する必要があります。平等のためだけに。したがって、並べ替え要求がある場合、並べ替えを使用するためにリストが存在しないように、すべてを結合して要求を再構築する必要があります。当然、これは常に可能とは限らず、常に便利とは限りません。たとえば、インデックスの拡張子によってインデックスカバーを作成できる場合（クエリで選択および使用されるすべてのフィールドがインデックスに存在することを意味します）、サーバーはデータのテーブルに登る必要がないことを理解し、要求しますインデックスに結果を形成します。なぜならインデックスはより合理化され、コンパクトで、ほとんどの場合キャッシュされたメモリに保存されます。これはより便利です。したがって、インデックスをコンパイルするときは、クエリのカバーインデックスを何らかの方法で選択できるかどうかを常に確認します。

さらに、インデックスを使用しない場合を検討します。

他のデータベースには共通の微妙な違いがあります。たとえば、PostgreSQLのようにインデックスが式の一部である場合、変換できません。したがって、クエリにid + 1 = 3がある場合、idのインデックスは使用されません。私たちは自分でそれを負担しなければなりません。インデックスが式の一部である場合、インデックスを明示的に除外できるように変換できるかどうかを確認する必要があります。

同様に、変換を実行しないという事実のため（数学的なだけでなく、エンコードの不一致、型変換など）、インデックスも使用されません。サフィックス検索が進行中の場合、最初の部分がスキップされるとき、インデックスは使用されません。もちろん、同様のテーブルのフィールドと比較する場合、インデックスは使用されません。この場合、比較するために最初にテーブルからレコードを読み取る必要があるためです。

その前に、インデックスをカバーすることと、それらがどのように優れているかについて言及しました。アーキテクチャスライドに戻る：

これは次のように発生します。請負業者は、店舗にデータ（WHERE条件）をそれぞれ要求します。複数のポジションにWHERE条件がある場合、それらはすべて店舗内で処理できます。これが最適なオプションです。条件の一部がインデックスによってストレージレベルで処理され、サーバーがレベルアップに渡された行を適用し、それ以上の条件を破棄するオプションがあります。明らかに、これは遅くなります、なぜならレコード自体がリポジトリから実行者に転送されます。したがって、インデックスをカバーすることは、クエリ内のフィールドにのみ適用する場合、より有益です。なぜなら、すでにより少ない行を選択しています。

ここで、たとえば、インデックス条件プッシュダウンと呼ばれる同様の最適化：

次の意味です。 A、B、Cの3つのフィールドにインデックスがあります。このような条件下では、最初のフィールドの一部のみを使用できます。リポジトリ自体のインデックスをチェックできるように思えますが、以前（MySQL 5.6、MariaDB 5.3より前）はサーバーがこれを実行していなかったため、特定のリリース（サーバーが実行できること）を注意深く調べる必要があります。新しいバージョンでは、サーバーは列Aのみでインデックスの最初の部分を検索し、データを選択します。レコードをエグゼキューターに送信する前に、2番目と3番目の部分の条件を確認し、レコード全体を選択するかどうかを確認します。これにより、ディスクから読み取る必要があるレコードの数が自然に減少します。

InnoDBの主要な機能は、セカンダリキーがプライマリキーを参照するため、実際にはInnoDBのセカンダリキーはセカンダリキー+プライマリキーへのポインタです。

このような長いインデックスには目に見えない尾があります。オプティマイザーがアクションでそれを考慮しなかったという意味で目に見えません。

したがって、プライマリ（A、B）コンポジット、セカンダリキーがあります-これは（C、A、B）のコンポジットキーになり、既に検索できます。

したがって、InnoDBテーブルを使用してインデックスを作成する場合、すべてのインデックスに追加されるため、使用するクエリに応じて、長いプライマリキーが良いか悪いかを常に考慮する必要があります。

次の警告があります-この最適化は、文字列のフィルタリングについてのみ考慮されます。セカンダリキーの値のみがソートされた形式で保存され、プライマリキーへのポインタはソートされないため、サーバーは等しい文字列フィルタリングの条件にのみこのような長く見えない「テール」を使用できます。 MariaDB 5.5、MySQL 5.6で利用可能です。

オプティマイザーの主な制限は、歴史的にほとんど統計を使用しないことです。リポジトリからのデータを要求します。ここで、サーバーが考慮に入れるものをより詳細に示します。

入力コマンド、フィールド、行数の結果を考慮することができます。大量のデータ。特徴は、最初に統計が次のように計算されることです：サーバーを起動するか、何らかのALTERコマンドを作成し、統計を更新します。その後、テーブルがしばらくの間存続し、プロセスが突然変化し、統計が再び更新されます。つまり統計自体がデータの分布に対応しないことが起こります。

繰り返しますが、各ストアは独自の方法で統計を選択します。最新バージョンでは、独立した統計、つまりサーバーレベルでの統計-サービステーブルが割り当てられ、Percona 5.6の場合、ストレージメカニズムに関係なく、すべてのテーブルの統計が統一された方法で収集されます。これはInnoDBのインデックスに対してのみ行われます。Maria10では、インデックス化されていない列についてもさらに収集し、データの分布をよりよく理解しているため、オプティマイザーはより最適な実行プランを選択できます。

オプティマイザーはリポジトリの機能を考慮しません。リクエストをリポジトリに転送すると、InnoDBがセカンダリキーをより長く検索することは明らかです。セカンダリキーを調べ、プライマリキーへのポインタを取得し、これらのポインタを取得し、データを取得するためです。つまりダブルパスを使用します。たとえば、MyISAMでは、行自体を直接指すポインターがすぐに存在します。オプティマイザーは、これらの部分またはそれらの部分の相対的な速度の同様のニュアンスを考慮しません（要求は異なるリポジトリーに同時に適用できます）。また、機器に関連する多くの問題も考慮していません。キャッシュしたデータ、バッファ...

メトリック。オプティマイザーが最も安いプランを選択することは明らかですが、オプティマイザーの観点から見ると、最も安いプランは最もコストの低いプランであり、コストの問題は、それに関する私たちの考えと一致しない慣習です。繰り返しますが、選択の難しさは、テーブルがたくさんあり、それらを移動して異なる方法で見る必要がある場合です。

彼はまた、ルールを使用しています。たとえば、フルテキストインデックスを使用する必要があることを理解している場合は、主キーに1つの列を明確に生成する条件がある場合でも、それを使用します。

まだそのようなニュアンスがあります-これらの2つのエントリは、私たちの観点からは同等です：

ここで、1と4の間

ここで、a> 0およびa <5

しかし、MySQLサーバーの観点からは、いいえ。 a> 0およびa <0の場合、彼は範囲検索を使用し、「between」を通じて同じものを記述する場合、これをリストに変換し、複数の等式の条件を使用できます。

このようなニュアンスでは、常識に基づいてクエリを作成することはできませんが、一方で、MySQLを最適化するために特別に訓練された人々の需要が増えるという点で便利です。 :)

オプティマイザーの仕組みについて簡単に説明します

自明性の要求をチェックします。一般に、彼はインデックス統計のみに基づいてリクエストを行うことができます。 ID列に負の値（正の値）を要求しているのかもしれません。その後、彼はすぐに私たちが範囲外で要求していることを理解します。これはパフォーマンスの点で非常に効果的なオプションです。最も安いプランを選択します。

オプティマイザーはほとんど何もできないように見えますが、実際にはさまざまな手法を使用してクエリを数学的に変換します。たとえば、サブクエリは古いバージョンのように低下したり、独立した依存関係になったり、新しいもののように改善したりする可能性があります。テクニックのリストは非常に長いです。

これは、MariaDBドキュメントの表の始まりです。

これらすべての単語の背後にあるものを知る必要があるので、MariaDBのドキュメントを参照することをお勧めします。それには明確な写真、イラストが装備されており、それらから何が何に属しているかを理解できます。

オプティマイザーにどのように影響を与えることができますか：

クエリの書き換えとは、同等の形式の書き込みを使用することです。たとえば、サブクエリを結合に置き換えるか、クエリを根本的に書き換えて、断片に分割し、一時的な中間テーブルにデータを書き込むか、一般的にテーブルを非正規化しますjoin'ovを取り除きます。
インデックス-必要なインデックスを追加するか、監視することができます。おそらく、統計を更新するだけです。
オプティマイザーのヒント-インデックスの使用/強制/無視-ソート、グループ化など、どの操作にどのインデックスを使用するかを明示的に指定できます。
straight_join-さまざまなオプションを反復しないように、テーブルを結合するための厳密な順序を設定できます。データの分布の特徴を知っており、作業する必要がある順序を知っているので、これを明確に示します。
@@ optimizer_switch-この変数を使用して、特定の追加最適化手法をすべて有効/無効にします。
変数optimizer_prune_levelおよびoptimizer_search_depthは、サーバーが最適なプランを選択する方法を決定します-すべての可能なオプションを反復するか、それを破棄します。多数の結合テーブルがあり、サーバーが数百万の順列を分析する場合、思慮深くなり、1秒で完了するには15分かかることがあるのは明らかです。したがって、このような状況が発生すると、これらの変数はすべてデフォルトで実行時間を制限します。これにより、計画が最適に選択されない可能性があります。最適化を実行するとき、テストモードでこれらの変数を変更して、サーバーがすべてのオプションを選択し、より最適なプランが選択されているかどうかを確認できます。

SQL_CALC_FOUND_ROWSは、最適化を完全に無効にする恐ろしい単語です。実際には、LIMITリクエストがある場合、キーワードをリクエストに含めることができ、サーバーは無制限に選択される合計数を含むレスポンスを提供します。これは、たとえば、ページのページネーションを行うときに便利であり、すべての自動システムがこれを引き起こします。 MySQLはCOUNTクエリを非常にうまく最適化できるため、これは悪いことですが、困難なケースでは、結合、グループなどがある場合、行数を個別にカウントし、結合の一部が結合するようにクエリを書き換えることができますグループの一部でも、ページの合計数に関する回答を得る必要はありません。

サーバーはリクエストごとに1つのメソッドのみを使用します。 FOUND_ROWSを追加すると、1つのメソッドで2つの問題が解決されます。彼は実際にすべての行を選択します。LIMITがない場合は、ストレージからデータを引き出します。すべての長いレコードは、余分なものを破棄すると信じています...これは非常に悪いことです。ここで、同じCOUNT（*）は行自体を読み取らず、データをリーダーに渡さずに、可用性の事実をスキャンするだけであるということを理解する必要があります。

このレベルでは、理解するために詳細を知る必要があります。そうしないと、単にEXPLAINを見るだけではあまり意味がありません。

EXPLAINの欠点は、オプティマイザーの欠点に起因します。 EXPLAINが要求を満たしていないが単に計画を立てていると言うとき、一般に、彼がしていることを書いていないが、ほとんど情報を出していないことがあります。古いバージョンでは、サブクエリから実行されていました。彼はサブクエリから一時的なサブテーブルに具体化し、それらが重い場合、サブクエリからこれらを完了するのに多くの時間がかかりました。また、サブクエリからデータを変更するユーザー定義関数が含まれる場合があり、EXPLAIN自体もデータを変更するという事実と矛盾がありました。なぜこれが必要なのかは明らかではありませんが、実際には人々は時々非常に奇妙なことを思いつきます。

EXPLAINの種類

PARTITIONSキーワードを使用すると、クエリが使用するセクションが表示されます。

EXTENDEDキーワードは、実行プランから復元されるSQLクエリを生成するという点で便利です。これは元のSQLクエリではなく、元のSQLクエリがプランに変換され、オプティマイザーによってプランから新しいSQLクエリが合成されます。オプティマイザーには、何が起こっているのかを理解できる多くのヒントが含まれています。キーを含む一時テーブルの形成、リクエストの一部のキャッシュ-これらのニュアンスはすべてドキュメントに詳しく説明されており、サーバーの機能、リクエストの変換方法の理解に役立ちます。

実際、これは最も単純なクエリのEXPLAINです。

ここでは、次を確認する必要があります。

使用されるアクセスのタイプ。最初のケースでは、すべてです-テーブル全体がスキャンされます。 2番目の場合、eq_refはキーによる直接検索であり、1つのレコードを形成します。
これが何らかの規則である場合、予想される行数。
possible_keysはオプティマイザが使用する予定のキーであり、keyは選択したキーです。たとえば、possible_key：NULLがあり、一部のキーがキー値にある場合、バリアントが可能です。これは、たとえば、SELECT FROMテーブルにWHERE句がない場合に発生します。オプティマイザーは、キーを使用する必要がないことを認識し、列がキーの一部であるように見えます。原則として、インデックスによって列を選択してから、カバーするインデックスを作成できます。したがって、possible_key：NULLであることが判明する可能性があり、keyはカバーインデックスであり、インデックスを使用することを意味します。
key_lenは、使用するインデックスの長さです。つまり、複合インデックスがある場合、key_lenを見ると、インデックスのどの部分を使用しているかがわかります。

さらに、すべての可能なオプションを詳細に検討することはしません-これはドキュメントに詳しく説明されています。

クエリに表示されるテーブルごとに1行を形成し、テーブルが表示される順序でクエリを実行することは明らかです。 EXPLAINを見ると、次のテーブルへのアクセス順序が選択されていることがすぐにわかります。最初に都市テーブルを選択し、次に国テーブルを選択します。ここではすべてが簡単です。

しかし、異なるUNION、FROMサブクエリなどを含むEXPLAINのような複雑なトリックがあり、長い「シート」が出力される場合：

質問が発生します-それを読む方法？

アイデアは非常に単純です。クエリに表示されるすべてのSELECTに番号を付け、SELECT番号はEXPLAINにある識別子番号に対応します。

わかりやすくするために、さまざまな色で強調表示しました。

2番目の警告-数字を見ることができます。たとえば、6-DERIVEDはFROMサブクエリです。次のものには、より大きな識別子が付いています。これは、同じFROMサブクエリ、つまり同じ一時テーブルに移動します。したがって、識別子だけを見ると、すでに多くの結論を引き出すことができます。

不便な点があります。行は順番に実行されると言います。実際、ビューなどが存在する場合、これは完全に真実ではありません。つまり UNIONを使用したクエリは、このように便利に読み取られます。4つのUNIONがあります。つまり、1〜4行目はUNIONの一部に関連し、4番目から最後は2番目の部分を参照します。つまり最後の行を見て上に行くことができるので、クエリを分割できます。実際、これには複雑なことは何もありません。スキルが必要です。

EXPLAINのグラフィカルな表現をすぐに構築するユーティリティがありますが、特に複雑なクエリの場合は理解しにくいため、それらを考慮しません。これは皆のためです。

EXPLAINが嘘をついている例

一部にサブクエリを含むクエリがあります。サブクエリは独立していますが、MariaDB 5.3およびMySQL 5.6より前のMySQLは多くの場合、これらのクエリを依存として実行していました。クエリのタイプは依存関係にありますが、一方でindex_subqueryタイプは表示されます。これは、実際にはサブクエリは実行されず、インデックスビュー関数に置き換えられることを意味します。つまりこれらの行は互いに競合し、反対のことについて話します。

質問が発生します-実際に何が起こるのですか、なぜなら EXPLAINは矛盾する情報を生成しますか？

プロファイリングをリクエストして確認できます：

右のように、リクエストが依存して実行される場合、リクエストの実行の一部であるデータ転送が複数になり、複製されます。クエリが個別に実行される場合、これらの値は複製されません。

さらに、プロファイリングは、ビッグデータの転送、統計のカウントなどのニュアンスを決定するのに便利です。

仕分け

ORDER BY id LIMIT 10000の場合、10は悪いため、サーバーは1万行すべてを選択し、さらに10行を選択し、1001行目を削除して10行のみを提供します。そのようなことは何らかの方法で変更する必要があります。または、IDが10,000を超えており、LIMIT 10です。サーバーが何をするかという点で、大きな数を相殺した場合、これは悪いことです。

ORDER BY rand（）は使用できません。この構造は、すべてのデータのコピーを作成し、それを一時テーブルにプッシュし、そこに別の列を追加し、そこにrand関数の結果を書き込み、この巨大な配列全体のファイルソートを行います。したがって、ランダムな行を選択する場合、ORDER BY rand（）は少量のデータでのみ使用でき、大量のデータではすぐにすべてのパフォーマンスが低下します。