MySQL クラスター化インデックスのソートが遅いケースの分析-mysql チュートリアル-php.cn

MySQL クラスター化インデックスのソートが遅いケースの分析

黄舟

リリース： 2017-01-20 17:13:09

オリジナル

1476 人が閲覧しました

大量の選択を実行するときに mysiam エンジンを使用する必要があるのはなぜですか?特にインデックスがある場合

この記事は実際のアプリケーションに基づいて分析しています。

1. はじめに:

1W のデータ量を持つテーブルがさまざまな orderby 条件を実行し、クエリ時間が非常に長いという興味深い現象を見かけました。これは実際のアプリケーションでは実際の問題でしょうか。 ?なぜ？

MySQL クラスター化インデックスのソートが遅いケースの分析

2. 分析

a) 状況の説明:

1. 主キー ID と結合インデックス (id、ver) があり、前者を使用すると orderby クエリが遅くなります。 orderby クエリを非常に高速化します

2. 各行のデータ量が非常に多くなります

3. ID がメインのインデックスであり、select クエリのフィールドには ID のみが含まれるため、インデックスの対象にはなりません。物理ディスクにアクセスせずにインデックスからデータを取得できますが、必要なデータには到達しますが、高速であるはずのクエリが遅くなります。 MySQL インデックスのカバレッジ

b) 分析:

は間違いなく mysiam エンジンを使用していません。そうであれば、物理行のアドレスがインデックスが存在するため、実際に占有されるデータ量は大きくありません。ただし、innodb の場合は異なります。行のすべてのデータはメインインデックスの下に保存されます。

c). 結論:

1. 主な理由: 使用される innodb エンジン

はクラスター化インデックスであり、主キー ID インデックスは行の他のデータもドラッグするため、ID に沿って並べ替える必要があります。各 ID をクエリして走査するには、多くの小さなブロックが必要です (mysiam の下にはそれほど多くのデータはありません。同じデータブロックを横断してより多くの行を走査するほうが高速です)

2. いくつかのフィールドがあります。家族連れが多く、データ量も比較的多い。各行のデータ量が多く、ディスクに保存するときに多くのブロックを占有します

3。この問題は当時の mysiam エンジンには存在しませんでした

d)。の選択が実行される場合は、mysiam エンジンを使用する必要があります

挿入と更新を実行する場合は innodb エンジンを使用します

詳細については、Mysql-index の概要を参照してください

3. 上記の条件を復元します。、連続テーブルを作成し、変数を制御します。エンジンが異なることを除き、残りの条件は同じで、主キー ID、主インデックス、結合インデックス (id、ver) です。

1. mysiam エンジンの新しいテーブル t7 を作成します

2. 10,000 個のデータをランダムに挿入します

MySQL クラスター化インデックスのソートが遅いケースの分析

明らかに、時間の差はそれほど大きくなく、すべて同じ桁です。

4. innodb エンジンで新しいテーブル t8 を作成します

MySQL クラスター化インデックスのソートが遅いケースの分析

5. 10,000 個のデータをランダムに挿入します

MySQL クラスター化インデックスのソートが遅いケースの分析上記のスクリプトに従ってステートメントを実行します。待機時間が非常に長いのはなぜですか?主キーインデックス ID を持つクラスター化インデックスであるため、主キーインデックスの作成時に大量の行データブロックが移動され、分割と移動に時間がかかります。