問題タブ [composite-index]

4列のInnodbテーブルを作成しています。

テーブル

論理的な観点から、列A、B、Cを一緒にPKにする必要がありますが、パフォーマンスを向上させ、インデックスから直接読み取ることができるようにするために（インデックスを使用）、4つの列すべてで構成されるPKを検討しています（A 、B、C、D）。

質問

Innodbテーブルの主キーに追加の列を追加した場合のパフォーマンスはどうなりますか？

考慮事項

• 代理主キーは絶対に問題外です
• このテーブルには他のインデックスは存在しません
• テーブルは読み取り/書き込みを多用します（どちらもほぼ等しい）

ありがとうございました！

3つの列（ドイツのバイグラム）を含む1GBのmysqlテーブルがあります。

複合インデックスも作成しました。

さらに、テーブルを圧縮して読み取り専用にし、次を使用してインデックスを並べ替えました。

ここで、次の構造でクエリを実行します。

• ソースを修正する
• ターゲットのプレフィックスを指定します
• スコアで上位k行を取得

次のように：

mysql Explainは、まだファイルソートを使用していることを教えてくれます！

クエリを次のように変更すると、次のようになります。

ファイルの並べ替えはありませんが、間違ったファイルの並べ替えが含まれています。

この議論から、descキーワードが問題であることがわかりました。したがって、以下をチェックします。

うまくいった完璧。

ただし、ターゲットではなく、スコアの降順で並べ替える必要があります。この方法でインデックスを作成する

ターゲットフィルターがファイルソートを生成するため、オプションではありません。そうでない場合、プレフィックスが長く、ソースが一般的な単語である場合、トラバースする必要のある要素の結果リストが非常に長くなる可能性があります。

私はどういうわけかこれに対する明白な解決策がないと感じていますか？

次のスキーマを持つMySqlテーブルを考えてみましょう

今、私は次のようなクエリが必要です

そしてまた

したがって、次のように2列の複合インデックスを検討しています。

と

1) インデックスは必要に応じて作成されますが、レコードが多数 (~ 数百万) の場合に機能しますか?

2) 適切なタイミングで適切なインデックスを使用すると、インデックスによってクエリが高速化されますか?

PS: クエリは必要ありませんsort/range selection。直接一致クエリのみが必要です。この要件に利用できるより良いインデックス作成スキームはありますか?

属性にインデックスを作成すると、この属性のツリーが作成されます。
しかし、複合属性を持つインデックスを作成するとどうなるでしょうか? 2 つのツリーが作成されますか。両方とも同じツリーの一部ですか？何？

私は MySQL を初めて使用し、既存のテーブル (約 200K 行を含む) にインデックスを追加する必要があります。

インデックスの恩恵を受ける必要があるクエリが 2 つあります。

と ：

(completed_time と deleted_time で) 複数列インデックスの導入を検討していますが、「s.completed_time が null でない」という条件が、これらのクエリで複合インデックスを使用する基準に一致するかどうかはわかりません。

• 何がベストか（複合インデックスまたは 2 つのインデックス）について何か考えはありますか? 「説明」を使用して最適なものを見つけようとしていますが、結果を解釈する方法がわかりません。

• より一般的には、(column1, column2) に複合インデックスを持つテーブルでは、column2 のみのフィルタリングではインデックスが使用されないことを理解しています。しかし、(column1 > MIN_VALUE) や (column1 is not null) のようなダミー条件を導入するのが正しい場合はどうなるでしょうか?

ありがとう！

次のクエリを検討してください

必要なデータセットを取得するには、(コメント アウトされた) CONTACTS client_id と OUTBOUND_MESSAGES client_id でフィルター処理する必要がありますが、これにより、パフォーマンスがミリ秒から数十分に変化します。

" AND CON.MM_CLIENT_ID = 1 " のない実行計画:

" AND CON.MM_CLIENT_ID = 1 " の実行計画:

上記をフォーマットして見やすくする方法についての提案は良いでしょう。

ID フィールドは主キーです。結合するすべての列にインデックスがあります。

外部キーを使用して複合インデックスを追加したときに、EF が外部キーのインデックスを削除したことに気付きました。したがって、複合インデックスをよりよく理解する必要があります:)

この回答を使用して複合インデックスを追加し、EF コードの最初の移行ファイルを生成しました。

複合インデックスの追加:

移行ファイル:

理解できないのは、外部キーのインデックスを削除する必要がある理由です。私の知る限り、プロパティは複数のインデックスで問題なく使用できます。では、なぜ落とされるのでしょうか。それは結合を遅くしませんか？

モデル：

マッピング：

Tournamentという名前のテーブルがあり、このテーブルの列が であると仮定しましょうId, Name, GameId, TypeId, cityId, Status, Format。Idとの列を除いNameて、これらの列のすべての組み合わせでこのテーブルを検索したいのですが、GameId & Statusorで検索できるということTypeId & CityId & StatusですStatus & Format。

ご覧のとおり、すべての検索オプションの数は次のとおりです。

これが私の質問です。インデックス作成の最適なシナリオとその理由は何ですか? 選択肢は、

1. 各列のインデックス。
2. すべての列の複合インデックス。

複合インデックスは単一インデックスよりも非常に高速であることは知っていますが、正しい順序で行えば、[GameId, TypeId, CityId, Status, Format]列に複合インデックスがあり、検索GameId = 1 & TypeId = 2 & CityId = 3 & Status = 5 & Format = 6がうまくいくように検索するとうまくいきますが、検索GameId = 1 & Format = 6すると、このクエリがどのように機能するかわかりませんSQL Server複合インデックスは単なるbツリーであり、複合インデックスのbツリーキーは左から右の列に並べられていることがわかっているので、十分に高速です。