MySQL の最適化には 3 つの側面が含まれます

データベースはインターネット アプリケーションにとって不可欠な基礎的な依存関係となっており、その中でもオープン ソース データベースとしての MySQL がより広く使用されています。最近、私はプロジェクトの開発に焦点を当てており、より多くのアプリケーション開発者が MySQL データベースをより良く利用できるようにしたいと考え、開発プロセスで使用されるデータベース最適化の原則をまとめました。

MySQL の最適化には主に 3 つの側面が含まれます。1 つ目は SQL ステートメントの最適化、2 つ目はテーブル構造の最適化です。ここでは主にインデックスの最適化を指します。サーバー構成の最適化。

1. SQL ステートメントの最適化

1) クエリ ステートメントでは、最初に、Where 句と OrderBy 句のインデックスを構築することを検討する必要がありますが、すべての SQL についても同様です。ステートメントでは最大でも 1 つのインデックスしか使用されず、あまりにも多くのインデックスを設定すると、挿入と更新中にオーバーヘッドが発生します。同時に、区別がほとんどないフィールドの場合は、explain キーを使用してインデックスを作成しないようにする必要があります。クエリ ステートメントの前に、SQL ステートメントの実行プランをチェックして、クエリ ステートメントがインデックスを使用しているかどうかを確認します。 IN と NOT IN

3) Where 内のフィールドに対する NULL の判断を避けるように努める必要があります。 NULL の判定はテーブル全体のスキャンにつながるため、

4)Where 句の接続条件として or を使用することは避けてください。フルテーブルスキャン; 5)

Where 副節の使用は避けるようにしてください。 = または <> 演算子も を実行します。

6) like "%abc%" または like "%abc" を使用すると、フルテーブルスキャンが行われますが、like "abc%" はインデックスを使用します。

7)Union 演算子を使用する場合、Union 演算子は結果をマージするときに結果を並べ替えるため、代わりに Union ALL を使用できるかどうかを検討する必要があります。この要件がない場合は、結果をマージして返すだけの Union ALL を使用する必要があります。これにより、パフォーマンスが大幅に向上します

Where 句では式演算子を使用しないでください。 9)

Where 句のフィールドでは関数を使用しないようにしてください。 Select SQL ステートメントの解析プロセス中に、「

」がすべての列の列名に変換されるため、Select ステートメントでは "*" を使用しないようにしてください。 、この作業はクエリを通じて行われます。データ ディクショナリが完了するときは、一定のオーバーヘッドが発生します。句は後ろから前に解析されるため、Where 句の最後にほとんどのレコードを除外できる制限を付けるようにしてください。 12) index(a ,b,c)

Where句の条件フィールドの出現順序はインデックスフィールドの出現順序と一致している必要があります。そうでない場合、結合インデックスは使用できません。 ; 13) From 句内のテーブルの出現順序も SQL

From 句は後ろから前に解析されます。 3と3以上のテーブルが接続されてクエリされる場合、最後に書かれたテーブルが最初に処理されます。クロステーブルをベーステーブルとして使用する必要があります

14) たとえば、次の SQL ステートメント、select dbInstanceIdentifier from DBInstance where id > 3 は、次のように置き換える必要があります。 select dbInstanceIdentifier from DBInstance where id >=4 、2 つのステートメントの実行結果は同じですが、パフォーマンスは異なります。前者が実行されると、最初に等しいレコードが検索されるため、後者の方が効率的です。 3 に続いて前方スキャンに進み、後者は 4 に等しいレコードを直接見つけます。 2.

テーブル構造の最適化 これは主にインデックスを正しく作成する方法を指します。これは、不合理なインデックスはクエリの完全なテーブル スキャンにつながり、インデックスが多すぎると挿入と更新のパフォーマンスのオーバーヘッドが発生するためです。

まず、各 SQL ステートメントは最大 1 つのインデックスしか使用できないことを明確にする必要があります。使用できるインデックスが複数ある場合、システムは実行用のインデックスを選択します。

2) Innodb テーブルの場合、ユーザーが主キーを指定しない場合、システムは主キー列を自動的に生成しますが、自動的に生成される主キー列は複数の問題1. パフォーマンスが不十分で、

2. 同時実行性が不十分で、システム内の主キーのないすべてのテーブルがグローバル Auto_Increment 列を共有します。したがって、InnoDB 内のすべてのテーブルは、テーブルの作成時に主キーを指定する必要があります。 3) ほとんど区別のないフィールドの場合は、インデックスを作成しないでください 4) 1 つのフィールドに対して 1 種類のインデックスを作成するだけでよく、一意のインデックスを作成する必要はありません。インデックスと別の

インデックス。 5)大きなテキストフィールドまたは

フィールドの場合は、インデックスを作成しないでください。

6) 接続クエリの接続フィールドにはインデックスが必要です。

7) 並べ替えフィールドには通常、インデックスが必要です。

8) グループ化統計フィールドにはインデックスが必要です。 ;

9) ジョイント インデックスを正しく使用します。たとえば、次のジョイント インデックス index(userID,dbInstanceID)、 はこれを使用できます。インデックス、select dbInstanceIdentifier from DBInstance where userID=? ですが、ステートメント select dbInstanceIdentifier from DBInstance where dbInstanceID=? はこのインデックスを使用できません。

10) インデックスは通常、より多くのレコードを持つテーブルに使用されます。テーブル DBInstance があり、すべてのクエリには userID 条件フィールドがあります。現時点では、このフィールドはレコードを非常によく区別できることが知られています。つまり、各 userID の下に多くのレコードは存在しないため、テーブルに必要なのはただし、他の条件フィールドを使用した場合でも、各 userID に対応するレコード データはそれほど多くないため、インデックスを作成せずに他のフィールドを同時に使用しても基本的に影響はありません。 、あまりにも多くのインデックスを確立することによって引き起こされる挿入と更新のパフォーマンスのオーバーヘッドも回避できます。 MySQL サーバー構成の最適化

サーバーには低速接続ログがあり、一定の時間を超える可能性があり、開発者の追跡を容易にするためにインデックスを使用しないクエリ ステートメントが記録されます。設定による接続ログ機能slow_query_log=ON/OFF、slow_query_log_file低速接続ログのファイル名を設定、long_query_timeタイムアウト時間、単位を設定 はいms、

MySQLデフォルトではオフになっています

2) MySQL にはクエリ キャッシュ機能があり、同じクエリによって発生するサーバーのオーバーヘッドを軽減するために、サーバーはクエリ ステートメントと対応する戻り結果を保存します。クエリ キャッシュを閉じることを意味しますが、テーブルが更新されると、すべてのクエリ キャッシュが無効になることに注意してください。デフォルトでは、MySQL はデータベースへの最大接続数を設定します。接続の最大保持時間は s です。デフォルトは 8 時間です。データベース接続を使用する場合、データベースは自動的に接続を切断します。接続プール内の接続がサーバーによって切断された可能性があるため、その時点では接続プールは認識せず、アプリケーションが接続プールから接続を取得して使用するときにエラーが発生します。 アプリケーションで複数の例外が発生した場合、データベースへのホスト接続が終了するように設定します

【関連する推奨事項】1. MySQL の無料オンライン ビデオ チュートリアル。最新のマニュアルチュートリアル3.データベース設計に関すること

以上がMySQL の最適化には 3 つの側面が含まれますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。