Составной индекс также хорош для запросов по первому полю?

Допустим, у меня есть таблица с полями Aи B. Я делаю регулярные запросы на A+ B, поэтому я создал составной индекс на (A,B). Будут Aли полностью оптимизированы запросы только по составному индексу?

Кроме того, я создал индекс A, но Postgres по-прежнему использует составной индекс только для запросов A. Если предыдущий ответ положительный, я думаю, это не имеет значения, но почему он выбирает составной индекс по умолчанию, если Aдоступен один индекс?

Это определенно. Мы обсудили это очень подробно под этим связанным вопросом:

• Работа индексов в PostgreSQL

Пространство выделяется в виде кратного числа MAXALIGN, которое обычно составляет 8 байт в 64-разрядной ОС или (гораздо реже) 4 байта в 32-разрядной ОС. Если вы не уверены, проверьте pg_controldata. Это также зависит от типов данных индексированных столбцов (некоторые требуют заполнения выравнивания) и фактического содержимого.

Индекс, скажем, для двух integerстолбцов (по 4 байта в каждом) обычно заканчивается точно таким же большим, как индекс только для одного, где еще 4 байта теряются при заполнении выравнивания.

В таком случае у планировщика запросов действительно нет недостатка в использовании индекса (a,b)- по сравнению с индексом только (a). И, как правило, для нескольких запросов предпочтительно использовать один и тот же индекс. Вероятность того, что он (или его части) окажется в (быстром) кэше, при совместном использовании возрастает.

Если вы уже поддерживаете индекс (a,b), тогда не имеет смысла создавать другой индекс просто (a)- если только он существенно не меньше. То же самое не относится к (b,a)против (a). Перейдите по ссылке в первой строке, чтобы узнать больше.

Если исходить из противоположного направления, когда вам нужен дополнительный индекс, подобный этому (a,b), подумайте о том, чтобы сбросить существующий индекс просто (a)- если это возможно. Часто это невозможно, поскольку это индекс PK или UNIQUEограничения. Начиная с Postgres 11 вы можете просто добавить bк определению ограничения INCLUDEвместо этого предложение. Подробности в руководстве.

Или создайте новый индекс (b,a)вместо этого, чтобы покрыть запросы только bдополнительно. Только для условий равенства порядок индексных выражений в индексах btree не имеет значения. Тем не менее, при использовании условий дальности. Видеть:

• Многоколонный индекс и производительность

Есть потенциальные недостатки включения дополнительных столбцов в индекс, даже если он использует только пробел, в противном случае теряется при заполнении выравнивания:

• Всякий раз, когда обновляется дополнительный столбец, индекс также нуждается в обновлении, что может увеличить стоимость операций записи и создать больше размазывания индекса.
• ГОРЯЧИЕ обновления (Heap Only Tuple) для таблицы невозможны, пока задействован какой-либо столбец индекса.

Подробнее о горячих обновлениях:

• Избыточные данные в операторах обновления

Как измерить размеры объекта:

• Измерьте размер строки таблицы 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?

Он будет использовать индекс только в том случае, если есть один или два предиката [A] или [A], [B]. Он не будет использовать его в порядке [B], [A] или [A], [C]. Чтобы иметь возможность использовать индекс с дополнительным столбцом [C], необходимо принудительно использовать индекс, упорядочив предикаты как [A], [B] и [C].