複合インデックスは、最初のフィールドのクエリにも適していますか？

フィールドAとを持つテーブルがあるとしましょうB。A+ Bで定期的にクエリを作成するため、で複合インデックスを作成しました(A,B)。クエリAも複合インデックスによって完全に最適化されますか？

さらに、にインデックスを作成しましたAが、Postgresはでのみクエリに複合インデックスを使用していAます。前の答えが正の場合、それは実際には重要ではないと思いますが、単一のAインデックスが利用可能な場合、デフォルトで複合インデックスを選択するのはなぜですか？

確かにそうです。この関連する質問の下で詳細に議論しました。

• PostgreSQLでのインデックスの機能

スペースはの倍数で割り当てられMAXALIGNます。これは通常、64ビットOSでは8バイト、32ビットOSでは（あまり一般的ではないが）4バイトです。不明な場合は、を確認してくださいpg_controldata。また、インデックス付き列のデータ型（一部にはアライメントパディングが必要）および実際のコンテンツにも依存します。

たとえば、2つのinteger列（各4バイト）のインデックスは、通常、1つだけのインデックスとまったく同じサイズになり、アライメントパディングのために別の4バイトが失われます。

そのような場合には上のインデックスを使用するクエリプランナには欠点が本当にありません(a,b)-ちょうど上のインデックスに比べて(a)。一般に、複数のクエリで同じインデックスを使用することをお勧めします。共有されると、その（またはその一部）が（高速）キャッシュに常駐する可能性が高まります。

のインデックスを既に保持している場合(a,b)、それだけで別のインデックスを作成することは意味がありません(a)- 大幅に小さい場合を除きます。vs.にも同じことが当てはまりません。詳細については、最初の行のリンクに従ってください。(b,a)(a)

反対方向から来て、そのような追加のインデックスが必要な場合は、可能であれば(a,b)既存のインデックスを削除することを検討して(a)ください。多くの場合、これはPKまたはUNIQUE制約のインデックスであるため不可能です。Postgres 11以降bでは、INCLUDE代わりに句を使用して制約定義に追加するだけで済みます。マニュアルの詳細。

または、(b,a)代わりに新しいインデックスを作成して、クエリをb追加でカバーします。等価条件の場合のみ、btreeインデックスのインデックス式の順序は関係ありません。ただし、範囲条件が関係する場合は実行されます。見る：

• 複数列のインデックスとパフォーマンス

アライメントパディングで失われたスペースのみを使用する場合でも、インデックスに追加の列を含めることには潜在的な欠点があります。

• 追加の列が更新されるたびに、インデックスの更新も必要になります。これにより、書き込み操作にコストがかかり、インデックスの膨張が増える可能性があります。
• テーブルのHOT更新（ヒープのみのタプル）は、インデックス列が関係している間は実行できません。

HOTアップデートの詳細：

• 更新ステートメントの冗長データ

オブジェクトサイズの測定方法：

• PostgreSQLテーブルの行のサイズを測定する

質問によると、フィールドAとBを持つテーブルがあります。クエリが次の場合：

SELECT * FROM [YOUR TBL]
WHERE A='XXXX'

オプティマイザは、抽出ランダムアクセスを回避するために複合インデックスを選択します！

述語で最初に使用するだけの場合です。

複合キーの最初の列と複合キーの非キー列を使用する場合、スキャンを実行します。

それをだますために、このようなダミーの述語だけでなく、非キー列を使用できます：

[A、B]はインデックス、[C]-別の列

インデックスを利用するには、次のように記述します。

SELECT
    A,B,C,D,E
FROM 
    test
WHERE
   A=1
AND
   B=B
AND 
   C=3

...単一のAインデックスが利用可能な場合、デフォルトで複合インデックスを選択するのはなぜですか？

1つまたは2つの述語[A]または[A]、[B]がある場合にのみ、インデックスを使用します。[B]、[A]または[A]、[C]の順序では使用しません。追加の列[C]でインデックスを利用できるようにするには、述語を[A]、[B]、および[C]として順序付けしてインデックスを適用する必要があります。