MySQL Advanced 13 - インデックスによる SQL の最適化-mysql チュートリアル-php.cn

MySQL Advanced 13 - インデックスによる SQL の最適化

黄舟

リリース： 2016-12-29 16:55:55

オリジナル

1299 人が閲覧しました

1.概要

バイナリツリー——>インデックスファイル:効率log2N

10回取得:2の10乗。 1024件のレコード。

インデックスによって生じるオーバーヘッド

データファイル（インストールディレクトリ下のデータディレクトリ）を見ると、3つのファイルが見つかります。

.frm: テーブルの構造を表します

.myd: データを表します

.myi: インデックス付きファイルを表します

インデックス作成によって生じる問題: 挿入、更新、削除の効率化につながります

頻繁に更新されるフィールドはインデックスの作成には適していません。

一意性が低いフィールドはインデックスの作成には適していません。例えば、人の性別が男性か女性の場合のみ

以下の条件を満たす場合にインデックスが作成されます

1 where条件でよく使われるはずです。

2. このフィールドはあまり頻繁には変更されません。

2. インデックスの使用シナリオ

1. where 条件を満たすレコードをすばやく検索します。

2. 候補セットを素早く決定します。 where 条件で複数のインデックスフィールドが使用されている場合、MySQL は条件を満たさないレコードをできるだけ早く削除するために、候補セットのサイズを最小化できるインデックスの使用を優先します。

3. テーブル内に複数のフィールドで構成される結合インデックスがある場合、レコードを検索するときに、この結合インデックスの左端のプレフィックス一致フィールドもインデックスとして自動的に使用され、検索が高速化されます。

例: テーブルに 3 つのインデックスが作成された場合、(c1, c2, c3) で構成される結合インデックスは、(c1)、(c1, c2)、(c1, c2, c3) としてすべて使用されます。 (c2,c3) はインデックスとして使用されず、(c1,c3) は実際には c1 インデックスのみを使用します。

4. 複数のテーブルで結合操作を実行するときにインデックスが使用されます (結合に参加しているフィールドがこれらのテーブルでインデックス付けされている場合)

5. フィールドがインデックス付けされている場合、このフィールドに対して並べ替えまたはグループ操作を実行するときに、 MySQL はインデックスを使用します。

3. EXPLAIN を通じて非効率な SQL の実行計画を分析します

例:

mysql> explain select * from taxgrouptaxes\G  
*************************** 1. row ***************************  
           id: 1  
  select_type: SIMPLE  
        table: taxgrouptaxes  
         type: ALL  
possible_keys: NULL  
          key: NULL  
      key_len: NULL  
          ref: NULL  
         rows: 1  
        Extra:

ログイン後にコピー

select_type: SELECT のタイプを示します。

共通の値は次のとおりです

SIMPLE: テーブル接続もサブクエリも使用されない単純なテーブル

PRIMARY: メインクエリ、外部クエリ

union: UNION の 2 番目以降のクエリステートメント

SUBQUERY: サブクエリの最初の選択

table: 結果セットを出力するテーブル

type は、 MYSQL がテーブル内で必要な行を見つける方法。またはアクセスタイプとも呼ばれます。

一般的なタイプには、

all

index

range

ref

eq_ref

const,system

null

が含まれており、上から下まで、パフォーマンスは最悪から最高の範囲にあります。

1: type=all フルテーブルスキャン。

2: type=index インデックススキャン

3: type=tange インデックス範囲スキャン。

4: type=ref 間の < <= > >= などの操作で一般的に使用され、一意のインデックススキャンまたは一意のインデックスのプレフィックススキャンが使用されます。

5: type=eq_ref は ref と似ていますが、異なる点は、使用されるインデックスが一意のインデックスであることです。テーブル内の 1 つのレコードのみが一致します。

6: type=const/system 1 つのテーブル内に一致する行は最大 1 つあり、クエリは非常に高速です。

7: type=null MYSQL はテーブルやインデックスにアクセスする必要はありません。結果を直接取得できます。

possible_keys: クエリで使用できるインデックスを示します

key: 実際に使用されるインデックスを示します

key_len: 使用されるインデックスフィールドの長さ

rows: スキャンされた行の数

Extra: 実行の説明とスキャン。表示に収まらない他の列を含めることは、実行計画にとって重要です。

4. show profile を使用して SQL を分析します

1. まず、MySQL が show profile をサポートしているかどうかを確認します

mysql> select @@have_profiling;
+------------------+
| @@have_profiling |
+------------------+
| YES              |
+------------------+
1 row in set (0.00 sec)

ログイン後にコピー

2. プロファイルが閉じられている場合は、set ステートメントを使用してセッションレベルでプロファイルを開くことができます

3.実行が完了したら、show profiles ステートメントを使用して現在の SQL の queryID を表示できます。

4. クエリ queryID のプロファイルを表示します

上記は、MySQL Advanced 13 - Optimizing SQL through Indexes の内容です。その他の関連コンテンツについては、PHP 中国語 Web サイト (m.sbmmt.com) に注目してください。