mysqlのインデックスが多すぎますか？
現在のデータベースの最適化に時間を費やしています。
私は特にインデックスを見ています。
いくつか質問があります：
- インデックスが多すぎるということはありますか？
- インデックスの速度はどうなりますか？
- インデックスの速度は低下しますか？
- インデックスを追加することをお勧めするのはいつですか？
- インデックスを追加するのはいつ悪い考えですか？
- 複数のインデックスと複数の列のインデックスの長所と短所は？
インデックスの速度はどうなりますか？
データ取得-SELECTステートメント。
インデックスの速度は低下しますか？
データ操作-INSERT、UPDATE、DELETEステートメント。
インデックスを追加することをお勧めするのはいつですか？
データ取得のパフォーマンスを向上させたいと思う場合。
インデックスを追加するのはいつ悪い考えですか？
大量のデータ操作が行われるテーブル-挿入、更新...
複数のインデックスと複数列のインデックスの長所と短所は？
カバリングインデックス（複数の列のインデックス）を処理する場合、クエリは、インデックス列の定義で左から右に列の順序を指定する必要があります。ステートメントの列の順序は重要ではなく、列1、2、および3の順序のみです。ステートメントを使用するには、インデックスを使用する前に列1への参照が必要です。列2または3への参照のみがある場合、1/2/3のカバーリングインデックスは使用できません。
MySQLでは、クエリ内のSELECT /ステートメントごとに1つのインデックスのみを使用できます（サブクエリ/などは別のステートメントと見なされます）。また、MySQLが許可するテーブルあたりのスペースの量には制限があります。さらに、インデックス付きの列で関数を実行すると、インデックスが役に立たなくなります-IE：
WHERE DATE(datetime_column) = ...
この質問に関するいくつかの答えには同意しません。
インデックスが多すぎるということはありますか？
もちろん。クエリで使用されていないインデックスを作成しないでください。冗長なインデックスを作成しないでください。 pt-duplicate-key-checker や pt-index-usage などのツールを使用して、不要なインデックスを見つけやすくします。
インデックスの速度はどうなりますか？
- WHERE句の検索条件。
- 参加条件。
- ORDER BYのいくつかのケース。
- GROUP BYのいくつかのケース。
- 一意の制約。
- 外部キーの制約。
- 全文検索。
他の回答では、INSERT/UPDATE/DELETEはインデックスが多いほど遅くなるとアドバイスされています。それは本当ですが、UPDATEとDELETEの多くの使用にはWHERE句もあり、MySQLではUPDATEとDELETEもJOINをサポートしていることを考慮してください。インデックスは、インデックスを更新するオーバーヘッドを補うよりも、これらのクエリに役立つ場合があります。
また、InnoDBはUPDATEまたはDELETEの影響を受ける行をロックします。彼らはこの行レベルのロックを呼び出しますが、それは本当にインデックスレベルのロックです。検索を絞り込むインデックスがない場合、InnoDBは変更する特定の行よりも多くの行をロックする必要があります。テーブルの行をロックallすることもできます。これらのロックは、論理的に競合しない場合でも、他のクライアントによる変更をブロックします。
インデックスを追加することをお勧めするのはいつですか？
上記のいずれかの場合にインデックスの恩恵を受けるクエリを実行する必要があることがわかっている場合。
インデックスを追加するのはいつ悪い考えですか？
インデックスが別の既存のインデックスの左プレフィックスである場合、またはインデックスが実行する必要のあるクエリのいずれにも役立たない場合。
複数のインデックスと複数列のインデックスの長所と短所は？
場合によっては、MySQLは index-merge Optimization を実行し、独立したインデックス検索の結果を結合または交差させることができます。ただし、単一のインデックスを定義するとパフォーマンスが向上するため、インデックスのマージを行う必要はありません。
コンサルティングの顧客の1人に対して、インデックスのない多対多のテーブルに複数列のインデックスを定義し、結合クエリを9,400万倍に改善しました。
適切なインデックスの設計は、最適化する必要があるクエリに基づいた複雑なプロセスです。 「すべてをインデックス化する」や「更新を遅らせるのを避けるために何もインデックス化しない」などの広範なルールを作成しないでください。
私のプレゼンテーションも参照してください 実際にインデックスを設計する方法 。
インデックスが多すぎるということはありますか？
インデックスには、テーブル、アプリケーションが実行するクエリなどの問題が通知されます。
インデックスの速度はどうなりますか？
選択。
インデックスの速度は低下しますか？
インデックスを更新する必要があるため、INSERTは遅くなります。
インデックスを追加することをお勧めするのはいつですか？
アプリケーションに別のWHERE句が必要な場合。
インデックスを追加するのはいつ悪い考えですか？
一意性制約をクエリまたは強制する必要がない場合。
複数のインデックスと複数列のインデックスの長所と短所？
質問がわかりません。複数の列を含む一意性制約がある場合は、必ずそのようにモデル化します。
インデックスが多すぎるということはありますか？
はい。 go outインデックスを作成しようとしないでください。必要に応じて作成してください。
インデックスの速度はどうなりますか？
インデックステーブル/ビューに対するクエリ。
インデックスの速度は低下しますか？
新しいレコードごとにインデックスを作成する必要があるため、インデックス付きテーブルに対するINSERTステートメントは遅くなります。
インデックスを追加することをお勧めするのはいつですか？
クエリが許容可能な速度で実行されていない場合。クラスター化されたPKの一部ではないレコードをフィルター処理する場合があります。その場合、検索対象のフィルターに基づいてインデックスを追加する必要があります（パフォーマンスが適切である場合）。
インデックスを追加するのはいつ悪い考えですか？
あなたがそれをするときそれのために-すなわち過剰最適化。
複数のインデックスと複数の列のインデックスの長所と短所は？
改善しようとしているクエリに依存します。
インデックスが多すぎるということはありますか？
うん、すべてのものと同様に、インデックスが多すぎるとデータ操作が遅くなります。
インデックスを追加することをお勧めするのはいつですか？
インデックスを追加するのは、クエリが遅すぎる（つまり、クエリの結合が多すぎる）場合です。この最適化は、パフォーマンスを調整するために、ソリッドモデルを構築した後にのみ使用する必要があります。