遅くて時間がかかるmysqlの左結合クエリの落とし穴をまとめて整理する

この記事は、mysql に関する関連知識を提供します。主に、SELECT ステートメントを分析するための EXPLAIN コマンドを含む、遅い左結合クエリと長時間の落とし穴の概要を次のように紹介します。見てください、それが皆さんのお役に立てば幸いです。

推奨される学習: mysql ビデオ チュートリアル

問題の背景

2 つのテーブルと 1 つはユーザー テーブル a (主キーは int 型）、1 つはユーザー固有情報テーブル b（ユーザーテーブル ID フィールドは varchar 型）です。

ユーザーとユーザー情報を表示したいので、関連するクエリを実行する必要がありますが、左結合後のクエリは遅く、時間がかかりすぎることがわかりました。ユーザーテーブルのデータは約20,000件あります。

#問題の分析と処理

1. EXPLAIN コマンドを使用して SELECT ステートメントを分析します

type このフィールドは、クエリが効率的かどうかを判断するための重要な基礎を提供します。type フィールドを通じて、クエリがフル テーブル スキャンであるかインデックス スキャンであるかを判断します。

ALL: フル テーブル スキャンを示します。このタイプのクエリはパフォーマンスが最も高く、最悪のクエリの 1 つです。

一般的に、クエリには ALL タイプのクエリを含めるべきではありません。そのようなクエリは、大量のクエリがデータベースのパフォーマンスに大きな影響を与えるからです。データが大きい場合 たとえば、クエリは ALL タイプのクエリであるため、一般的に、これを回避するには、対応するフィールドにインデックスを追加できます。

2. 新しいインデックス

テーブル内のフィールド b のインデックスが以前に作成されていないことが判明したためです。

もう一度分析を説明します

異なるタイプの性能関係を比較した結果、タイプが ref に変更されていることがわかります (

) 大丈夫そうな気がしたので、クエリを実行しました。

3. インデックス フィールドの型を変更して一貫性を保つ

クエリを実行した後、実行速度が最適化されていないことがわかりました。以前の同僚が設計したテーブルを使用したところ、インデックス タイプ フィールドが矛盾していることが判明したため、varchar から int に変更して再度クエリを実行したところ、クエリ速度が大幅に向上したことがわかりました。

以前Javaコードに書いた文字列がデータベース内でintに変更されていても、今回のテストは正常に使用できます

まとめ

問題を解決した後、開発マニュアルをめくってみると、インデックス仕様では、結合中にデータ型が一貫している必要があり、関連フィールドにはインデックスが必要であることが明確に義務付けられていることがわかりました。 ！ ！

推奨学習:

mysql ビデオ チュートリアル

以上が遅くて時間がかかるmysqlの左結合クエリの落とし穴をまとめて整理するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。