Постгреси та індекси на іноземні та первинні ключі


344

Чи Postgres автоматично ставить індекси на іноземні та первинні ключі? Як я можу це сказати? Чи є команда, яка поверне всі індекси на таблицю?

Відповіді:


406

PostgreSQL автоматично створює індекси на первинних ключах і унікальних обмежень, але не на стороні, що посилається на зовнішні зв'язки ключів.

Коли Pg створює неявний індекс, він випромінює NOTICEповідомлення-рівня, яке ви можете бачити в psqlта / або системних журналах, щоб ви могли бачити, коли це відбувається. Автоматично створені індекси також видно у \dвисновку для таблиці.

Документації унікальних індексів говорить:

PostgreSQL автоматично створює індекс для кожного унікального обмеження та обмеження первинного ключа для забезпечення унікальності. Таким чином, не обов’язково створювати індекс явно для стовпців первинного ключа.

а документація про обмеження говорить:

Оскільки ВИДАЛЕННЯ рядка з посиланої таблиці або ОНОВЛЕННЯ посилального стовпця вимагатиме сканування таблиці реферування для рядків, що відповідають старому значенню, часто корисно проіндексувати стовпці посилань. Оскільки це не завжди потрібно, і існує багато варіантів, як індексувати, декларування обмеження іноземного ключа автоматично не створює індекс на стовпчикових стовпцях.

Тому вам доведеться самостійно створювати індекси на іноземних ключах, якщо ви хочете їх.

Зауважте, що якщо ви використовуєте первинні-іноземні ключі, наприклад, 2 FK в якості ПК у таблиці M-to-N, у вас буде індекс PK і, ймовірно, не потрібно створювати зайвих індексів.

Хоча, як правило, добре створити індекс на (або включати) стовпці сторонніх ключів на стороні референції, це не потрібно. Кожен доданий вами індекс трохи уповільнює операції DML, тому ви платите за ефективність кожного INSERT, UPDATEабо DELETE. Якщо індекс використовується рідко, можливо, його не варто мати.


26
Я сподіваюся, що це редагування нормально; Я додав посилання на відповідну документацію, цитата, яка робить абсолютно явним, що сторона посилань на FK відносини не дає неявного індексу, показала, як бачити індекси в psql, переформулювала 1-й параметр для наочності і додала зауважте, що індекси не є вільними, тому не завжди правильно їх додавати.
Крейг Рінгер

1
@CraigRinger, як визначити, чи перевага індексу перевищує його вартість? Чи повинен я перевіряти профільні одиниці до / після додавання індексу і перевіряти загальний коефіцієнт підвищення продуктивності? Або є кращий спосіб?
Гілі

2
@Gili Це тема окремого питання щодо dba.stackexchange.com.
Крейг Рінгер

34

Якщо ви хочете перерахувати в програмі індекси всіх таблиць у ваших схемах, вся інформація знаходиться в каталозі:

select
     n.nspname  as "Schema"
    ,t.relname  as "Table"
    ,c.relname  as "Index"
from
          pg_catalog.pg_class c
     join pg_catalog.pg_namespace n on n.oid        = c.relnamespace
     join pg_catalog.pg_index i     on i.indexrelid = c.oid
     join pg_catalog.pg_class t     on i.indrelid   = t.oid
where
        c.relkind = 'i'
    and n.nspname not in ('pg_catalog', 'pg_toast')
    and pg_catalog.pg_table_is_visible(c.oid)
order by
     n.nspname
    ,t.relname
    ,c.relname

Якщо ви хочете детальніше поглибитись (наприклад, стовпці та замовлення), вам потрібно подивитися на pg_catalog.pg_index. Використання psql -E [dbname]зручно для з'ясування способів запиту до каталогу.


4
+1, оскільки використання pg_catalog та psql -E дійсно дуже корисне
Ghislain Leveque

"Для довідки \diтакож будуть перераховані всі індекси в базі даних." (коментар скопійовано з іншої відповіді, стосується і тут)
Risadinha

33

Цей запит містить список відсутніх індексів на зовнішніх ключах , оригінальне джерело .

Редагувати : Зауважте, що він не перевірятиме невеликі таблиці (менше 9 МБ) та деякі інші випадки. Дивіться остаточну WHEREзаяву.

-- check for FKs where there is no matching index
-- on the referencing side
-- or a bad index

WITH fk_actions ( code, action ) AS (
    VALUES ( 'a', 'error' ),
        ( 'r', 'restrict' ),
        ( 'c', 'cascade' ),
        ( 'n', 'set null' ),
        ( 'd', 'set default' )
),
fk_list AS (
    SELECT pg_constraint.oid as fkoid, conrelid, confrelid as parentid,
        conname, relname, nspname,
        fk_actions_update.action as update_action,
        fk_actions_delete.action as delete_action,
        conkey as key_cols
    FROM pg_constraint
        JOIN pg_class ON conrelid = pg_class.oid
        JOIN pg_namespace ON pg_class.relnamespace = pg_namespace.oid
        JOIN fk_actions AS fk_actions_update ON confupdtype = fk_actions_update.code
        JOIN fk_actions AS fk_actions_delete ON confdeltype = fk_actions_delete.code
    WHERE contype = 'f'
),
fk_attributes AS (
    SELECT fkoid, conrelid, attname, attnum
    FROM fk_list
        JOIN pg_attribute
            ON conrelid = attrelid
            AND attnum = ANY( key_cols )
    ORDER BY fkoid, attnum
),
fk_cols_list AS (
    SELECT fkoid, array_agg(attname) as cols_list
    FROM fk_attributes
    GROUP BY fkoid
),
index_list AS (
    SELECT indexrelid as indexid,
        pg_class.relname as indexname,
        indrelid,
        indkey,
        indpred is not null as has_predicate,
        pg_get_indexdef(indexrelid) as indexdef
    FROM pg_index
        JOIN pg_class ON indexrelid = pg_class.oid
    WHERE indisvalid
),
fk_index_match AS (
    SELECT fk_list.*,
        indexid,
        indexname,
        indkey::int[] as indexatts,
        has_predicate,
        indexdef,
        array_length(key_cols, 1) as fk_colcount,
        array_length(indkey,1) as index_colcount,
        round(pg_relation_size(conrelid)/(1024^2)::numeric) as table_mb,
        cols_list
    FROM fk_list
        JOIN fk_cols_list USING (fkoid)
        LEFT OUTER JOIN index_list
            ON conrelid = indrelid
            AND (indkey::int2[])[0:(array_length(key_cols,1) -1)] @> key_cols

),
fk_perfect_match AS (
    SELECT fkoid
    FROM fk_index_match
    WHERE (index_colcount - 1) <= fk_colcount
        AND NOT has_predicate
        AND indexdef LIKE '%USING btree%'
),
fk_index_check AS (
    SELECT 'no index' as issue, *, 1 as issue_sort
    FROM fk_index_match
    WHERE indexid IS NULL
    UNION ALL
    SELECT 'questionable index' as issue, *, 2
    FROM fk_index_match
    WHERE indexid IS NOT NULL
        AND fkoid NOT IN (
            SELECT fkoid
            FROM fk_perfect_match)
),
parent_table_stats AS (
    SELECT fkoid, tabstats.relname as parent_name,
        (n_tup_ins + n_tup_upd + n_tup_del + n_tup_hot_upd) as parent_writes,
        round(pg_relation_size(parentid)/(1024^2)::numeric) as parent_mb
    FROM pg_stat_user_tables AS tabstats
        JOIN fk_list
            ON relid = parentid
),
fk_table_stats AS (
    SELECT fkoid,
        (n_tup_ins + n_tup_upd + n_tup_del + n_tup_hot_upd) as writes,
        seq_scan as table_scans
    FROM pg_stat_user_tables AS tabstats
        JOIN fk_list
            ON relid = conrelid
)
SELECT nspname as schema_name,
    relname as table_name,
    conname as fk_name,
    issue,
    table_mb,
    writes,
    table_scans,
    parent_name,
    parent_mb,
    parent_writes,
    cols_list,
    indexdef
FROM fk_index_check
    JOIN parent_table_stats USING (fkoid)
    JOIN fk_table_stats USING (fkoid)
WHERE table_mb > 9
    AND ( writes > 1000
        OR parent_writes > 1000
        OR parent_mb > 10 )
ORDER BY issue_sort, table_mb DESC, table_name, fk_name;

7
Здається, не працює. Повертає 0 рядків, коли я знаю, що в них є стовпці без індексів, які посилаються на таблиці посилань.
juanitogan

6
@juanitogan Слідкуйте за умовами where: Серед інших, вони враховують лише таблиці, розмір яких перевищує 9 Мб.
Маттіас

@Matthias - Ах, зрозумів. Дякую. Так, я, очевидно, не потребував часу, щоб прочитати код. Це не було досить критично, щоб турбувати. ОП міг згадати обмеження. Можливо, я ще раз перевіряю це.
juanitogan

@SergeyB, схоже, дає хибний позитив на посилаються стовпці, які мають обмеження для первинного ключа, таким чином, автоматично мають індекс, але запит все ще їх позначає.
Дебасіш Мітра

21

Так - для первинних ключів, ні - для зовнішніх ключів (докладніше в документах ).

\d <table_name>

у "psql" відображається опис таблиці, що включає всі її індекси.


11
Для довідки \ di також буде перераховано всі індекси в базі даних.
Daemin

14

Мені подобається, як це пояснено у статті Прохолодні характеристики продуктивності EclipseLink 2.5

Індексація іноземних ключів

Перша особливість - автоматична індексація сторонніх ключів. Більшість людей неправильно припускають, що бази даних за замовчуванням індексують сторонні ключі. Ну, вони не роблять. Первинні ключі автоматично індексуються, а зовнішні - ні. Це означає, що будь-який запит на основі зовнішнього ключа буде виконувати повне сканування таблиці. Це будь-які відносини OneToMany , ManyToMany або ElementCollection , а також багато відносин OneToOne , а також більшість запитів на будь-які відносини, що включають об'єднання або порівняння об'єктів . Це може бути основною проблемою, і ви завжди повинні індексувати ваші закордонні поля.


5
Якщо ми завжди повинні індексувати свої поля із зовнішніми ключами, чому б двигуни бази даних вже не робили цього? Мені здається, в цьому є більше, ніж очі.
Бобборт

3
@Bobort З моменту додавання індексу передбачено покарання за ефективність усіх вставлень, оновлень та видалень, а також багато іноземних ключів у цьому випадку дійсно можна скласти. Тому я вважаю, що така поведінка є дозволеною - розробник повинен зробити свідомий вибір у цьому питанні. Можуть також бути випадки, коли зовнішній ключ використовується для забезпечення цілісності даних, але його не запитують часто або взагалі запитують - у цьому випадку покарання за виконання індексу буде нічим
Dr.Strangelove

3
Також є складні випадки зі складними індексами, оскільки вони застосовуються зліва направо: тобто складний індекс на [user_id, article_id] в таблиці коментарів ефективно охоплюватиме як запити ВСІХ коментарів користувача (наприклад, для показу зведеного журналу коментарів на веб-сайті), так і отримання всіх коментарі, зроблені цим користувачем для певної статті. Додавання окремого індексу на user_id в цьому випадку фактично є витратою дискового простору та процесорного часу на вставки / оновлення / видалення.
Dr.Strangelove

2
Ага! Тоді порада погана! НЕ слід завжди індексувати свої зовнішні ключі. Як зазначав @ Dr.Strangelove, насправді бувають випадки, коли ми не хочемо їх індексувати! Дуже дякую, доктор!
Боборт

Чому вони не індексуються за замовчуванням? Чи є важливий випадок використання, який робить це необхідним?
Адам Арольд

7

Для a PRIMARY KEY, буде створено індекс із таким повідомленням:

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "index" for table "table" 

Для FOREIGN KEY, обмеження не буде створено , якщо немає індексу на Посилання на сайти ед таблиці.

Індекс Посилання на сайти ІНГ таблиці не потрібно (хоча бажано), і , отже , не буде створена неявно.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.