MySQL クエリの効率とクエリ速度の最適化を向上させる方法は何ですか?

1. EXPLAIN キーワードを使用してクエリ ステートメントの欠陥を評価します

作成者は、次の図に示すように、データベース内で単純な Select クエリ ステートメントを実行して、テーブル内のすべての情報を取得しました。ここで、データベース管理者は、このステートメントの実行時にデータベースがどのような作業を行ったか、またはこのクエリ ステートメントをさらに最適化する可能性があるかどうかを知りたいと考えています。この情報を知りたい場合は、クエリ ステートメントに Explain キーワードを追加できます。

テーブル内のデータは、Select クエリ ステートメントを通じてデータベースからクエリできます。実行効率と最適化の余地は、この単純なクエリ ステートメントから導き出すことはできません。より詳細な情報を理解するには、Explain キーワードを追加する必要があります。次の図に示すように、

Explain キーワードを追加した後、システムはテーブル内のデータをクエリせず、クエリ プロセス中に一部の情報を表示するだけです。この情報は、その後のデータベース クエリの最適化に非常に役立ちます。上記の情報から、ユーザーが単純なクエリを作成しただけであることがわかります。このクエリでは、インデックス、キーワード、Where ステートメントは使用されません。このため、このクエリ ステートメントはあまり合理的ではありません。最終的に正しい結果を見つけることはできますが、クエリの効率はあまり明らかではない場合があります。この目的のために、データベースの専門家は上記の情報に基づいて最適化を実行できます。次の図に示すように、クエリに WHERE ステートメントを追加すると、結果はどうなるでしょうか?

Where ステートメントが最後の Extra フィールドで使用されると、システムはそれが使用されたことを表示します。データベースの最適化中に、NULL フィールドまたは結果に空のコンテンツを含むフィールドをキャプチャする必要があります。多くの場合、これらの場所が最適化の焦点となります。図に示すように、テーブルにキーワードまたはインデックスを設定することで、この Select ステートメントを最適化し、クエリの効率を向上させることができます。

2. データを比較するときに同じ型の列を使用してクエリ効率を向上させます

データをクエリする際、条件文に判定条件を追加することがあります。ユーザー基本情報テーブルとユーザー権限テーブルの 2 つのテーブルがあり、ユーザー番号ごとに関連付けられています。各ユーザーの権限情報を照会するには、ユーザー番号を照会条件として使用する必要があります。ここで、ユーザー基本情報テーブルのユーザー番号フィールドの型が CHAR、ユーザー権限テーブルのユーザー番号フィールドの型が VARCHAR であるとします。これら 2 つのデータ型はどちらも文字型ですが、同じ型ではありません。さて、これら 2 つのテーブルに対して相関クエリを実行するときのクエリ効率はどのくらいでしょうか? 最初に判断する必要があるのは、これらは異なる種類の文字データであっても、相互に互換性があるかどうかです。最終的には正しい結果を得ることができます。この点を明確にした上で、このクエリ ステートメントが最適化できるかどうかを考えてみましょう

別の仮定を立ててみましょう。現在、両方のテーブルのユーザー番号のデータ型は CHAR です。次に、これら 2 つのテーブルに対して関連するクエリを実行します。得られる結果は同じですか? テストの結果、クエリの結果は同じですが、費やした時間は異なります。データの量が増加するにつれて、2 つのクエリ間の時間差はますます長くなります。ここから、2 つのクエリ ステートメントは同等ですが、クエリ効率が異なることがわかります。

MySQL データベースではデータ型に互換性がありますが、比較は可能です。ただし、クエリの効率は影響を受けます。データベース クエリの効率を向上させるために、著者は、クエリ条件ステートメントで同じ種類の列を比較するのが最善であると推奨しています。同じ条件下では、同じ列タイプの方が、異なるタイプの列よりも優れたパフォーマンスを提供できます。これは、大量のデータを含むデータベースでは特に重要です。

ただし、この最適化にはデータ テーブルの列タイプを含める必要があります。このため、データ テーブルを設計する際にはこれを考慮する必要があります。上記の場合、これら 2 つのテーブルにユーザー ID 列を具体的に追加できます。一連の整数型を使用して、システムが自動的に番号を付けることができます。次に、クエリを実行するときに、元のユーザー番号列を介して比較するのではなく、このユーザー ID 列を介して比較します。相対的にクエリ操作の効率が高くなります。

3. Like キーワードの先頭にワイルドカードを使用する場合は注意してください

実際の作業で、著者は多くのデータベース管理者が悪い習慣を持っていることに気付きました。 Like などのキーワードを使用する場合、ワイルドカードがランダムに使用されます。たとえば、ユーザーは「LOOK」という接頭辞が付いたすべての製品情報を検索する必要があります。クエリを実行するとき、ユーザーは通常、「%LOOK%」のようなステートメントを使用することに慣れています。この条件ステートメントは、LOOK という接頭辞が付いた製品情報のみを取得するのではなく、製品名に LOOK という単語を含むすべてのレコードを取得します。

ただし、最終結果は同じになる可能性があります。ただし、この 2 つのクエリ効率は異なります。実際、この問題の大部分は、クライアント アプリケーションの不適切な設計によって引き起こされます。たとえば、クライアント アプリケーションを設計する場合、システムはデフォルトで % 記号を表示します。以下に示すように。

この設計の意図は優れており、システムがあいまいクエリをサポートできるようになります。しかし、実際の操作ではユーザーが問題を抱えている可能性があります。ユーザーがクエリ時に % の前に LOOK という単語を入力せず、% の後に単語を入力した場合。クエリを実行すると、カーソルは自動的に % 記号の後ろに配置されるためです。通常、ユーザーは入力時にカーソルの位置を調整しません。この時、上記のような状況が発生しました。

予期せぬ状況を避けるために、著者は、「Like」の後にワイルドカードを続けるようなキーワードを使用するときは十分に注意することを強くお勧めします。特に大量のデータからレコードを検索する場合は、このワイルドカードの位置を適切な場所で使用する必要があります。最初に別のワイルドカードを使用できる場合は、ワイルドカードを使用しないようにしてください。

4. Like キーワードを他の形式で置き換えてみる

前述したように、Like キーワードを使用するときはワイルドカードの位置に注意する必要があります。クエリ効率の観点から、ワイルドカードの位置に注意し、「Like」キーワードの使用をできるだけ避ける必要があります。実際、SQL ステートメントでは、他のメソッドを使用して Like キーワードを置き換えることができます。たとえば、6 桁の番号を持つ商品テーブルがあります。次に、9 で始まる製品番号をクエリする必要があります。これを行うにはどうすればよいですか?

まず、LIKE "9%" などの Like キーワードを使用します。このワイルドカードの位置に注意してください。この条件ステートメントにより、必要な結果を見つけることができます。しかし、パフォーマンスの最適化の観点から見ると、このステートメントは適切な対処方法ではありません。いくつかの妥協によってこれを達成することもできます。

2 つ目は、シンボルを比較することによって実現されます。この文は次のように再定式化できます。 これは、900000 ～ 999999 の値を持つメソッドを使用することで実現できます。ただし、両方のクエリの結果は同じです。ただし、このステートメントのクエリ時間は、Like 記号を使用した上記のステートメントよりもはるかに短くなります。

以上がMySQL クエリの効率とクエリ速度の最適化を向上させる方法は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。