Postgres et index sur les clés étrangères et les clés primaires


344

Postgres place-t-il automatiquement des index sur les clés étrangères et les clés primaires? Comment savoir? Existe-t-il une commande qui retournera tous les index d'une table?

Réponses:


406

PostgreSQL crée automatiquement des index sur les clés primaires et les contraintes uniques, mais pas sur le côté de référencement des relations de clés étrangères.

Lorsque Pg crée un index implicite, il émet un NOTICEmessage de niveau que vous pouvez voir dans psqlet / ou les journaux système, afin que vous puissiez voir quand cela se produit. Les index créés automatiquement sont également visibles dans la \dsortie d'une table.

La documentation sur les index uniques indique:

PostgreSQL crée automatiquement un index pour chaque contrainte unique et contrainte de clé primaire pour renforcer l'unicité. Ainsi, il n'est pas nécessaire de créer un index explicitement pour les colonnes de clé primaire.

et la documentation sur les contraintes dit:

Étant donné que la suppression d'une ligne de la table référencée ou la mise à jour d'une colonne référencée nécessitera une analyse de la table de référence pour les lignes correspondant à l'ancienne valeur, il est souvent judicieux d'indexer les colonnes de référence. Étant donné que cela n'est pas toujours nécessaire et qu'il existe de nombreux choix disponibles sur la façon d'indexer, la déclaration d'une contrainte de clé étrangère ne crée pas automatiquement un index sur les colonnes de référence.

Par conséquent, vous devez créer vous-même des index sur les clés étrangères.

Notez que si vous utilisez des clés étrangères primaires, comme 2 FK en tant que PK dans une table M-to-N, vous aurez un index sur le PK et vous n'aurez probablement pas besoin de créer d'index supplémentaires.

Bien que ce soit généralement une bonne idée de créer un index sur (ou incluant) vos colonnes de clé étrangère côté référencement, ce n'est pas obligatoire. Chaque index que vous ajoutez ralentit légèrement les opérations DML, vous payez donc un coût de performance pour chaque INSERT, UPDATEou DELETE. Si l'index est rarement utilisé, cela ne vaut peut-être pas la peine.


26
J'espère que cette modification est OK; J'ai ajouté des liens vers la documentation pertinente, une citation qui rend tout à fait explicite que le côté de référence des relations FK ne produit pas d'index implicite, a montré comment voir les index en psql, reformulé le 1er pair pour plus de clarté et ajouté un notez que les index ne sont pas gratuits donc il n'est pas toujours correct de les ajouter.
Craig Ringer

1
@CraigRinger, comment déterminez-vous si l'avantage d'un indice dépasse son coût? Dois-je profiler les tests unitaires avant / après l'ajout d'un index et vérifier un gain de performance global? Ou existe-t-il une meilleure façon?
Gili

2
@Gili C'est un sujet pour une question dba.stackexchange.com distincte.
Craig Ringer

34

Si vous souhaitez lister les index de toutes les tables de vos schémas de votre programme, toutes les informations sont à portée de main dans le catalogue:

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

Si vous souhaitez approfondir (comme les colonnes et la commande), vous devez regarder pg_catalog.pg_index. L'utilisation psql -E [dbname]est utile pour déterminer comment interroger le catalogue.


4
+1 parce que l'utilisation de pg_catalog et psql -E est vraiment très utile
Ghislain Leveque

"Pour référence \di, tous les index de la base de données seront également répertoriés." (le commentaire copié de l'autre réponse s'applique ici également)
Risadinha

33

Cette requête répertorie les index manquants sur les clés étrangères , source d'origine .

Edit : Notez qu'il ne vérifiera pas les petites tables (moins de 9 Mo) et certains autres cas. Voir WHEREdéclaration finale .

-- 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
Ne semble pas fonctionner. Renvoie 0 ligne lorsque je sais que j'ai des colonnes sans index sur elles qui référencent les tables de domaine.
juanitogan

6
@juanitogan Regardez les whereclauses: Entre autres, il ne prend en compte que les tableaux dont la taille est supérieure à 9 Mo.
Matthias

@Matthias - Ah, j'ai compris. Merci. Ouais, je n'ai évidemment pas pris le temps de lire le code. Ce n'était pas assez critique pour déranger. L'OP aurait pu mentionner les limites. Peut-être que je vais vérifier à nouveau un jour.
juanitogan

@SergeyB il semble donner un faux positif sur les colonnes référencées ayant une contrainte de clé primaire sur elles, ayant ainsi automatiquement un index mais la requête les marque toujours.
Debasish Mitra

21

Oui - pour les clés primaires, non - pour les clés étrangères (plus dans la documentation ).

\d <table_name>

dans "psql" montre une description d'une table incluant tous ses index.


11
Pour référence \ di listera également tous les index de la base de données.
Daemin

14

J'adore la façon dont cela est expliqué dans l'article Fonctionnalités de performances intéressantes d'EclipseLink 2.5

Indexation des clés étrangères

La première fonctionnalité est l'indexation automatique des clés étrangères. La plupart des gens supposent à tort que les bases de données indexent les clés étrangères par défaut. Eh bien, non. Les clés primaires sont indexées automatiquement, mais pas les clés étrangères. Cela signifie que toute requête basée sur la clé étrangère effectuera des analyses complètes de table. Ceci est tout OneToMany , ManyToMany ou ElementCollection relation, ainsi que de nombreux ONEtoONE relations, et la plupart des requêtes sur toute relation impliquant des jointures ou des comparaisons d'objets . Cela peut être un problème de performance majeur et vous devez toujours indexer vos champs de clés étrangères.


5
Si nous devons toujours indexer nos champs de clés étrangères, pourquoi les moteurs de base de données ne le font-ils pas déjà? Il me semble qu'il y a plus que cela à l'œil nu.
Bobort

3
@Bobort Étant donné que l'ajout d'index entraîne une baisse des performances sur toutes les insertions, mises à jour et suppressions, et de nombreuses clés étrangères pourraient vraiment s'additionner dans ce cas. C'est pourquoi ce comportement est opt-in, je suppose - le développeur devrait faire un choix conscient à cet égard. Il pourrait également y avoir des cas où la clé étrangère est utilisée pour appliquer l'intégrité des données, mais n'est pas interrogée souvent ou interrogée du tout - dans ce cas, la pénalité de performance de l'index ne servirait à rien
Dr.Strangelove

3
Il existe également des cas délicats avec des indices composés, car ceux-ci sont appliqués de gauche à droite: c'est-à-dire que l'index composé sur [user_id, article_id] sur la table des commentaires couvrirait à la fois l'interrogation de TOUS les commentaires par utilisateur (par exemple pour afficher le journal des commentaires agrégés sur le site Web) et la récupération de tous commentaires faits par cet utilisateur pour un article spécifique. L'ajout d'un index distinct sur user_id dans ce cas est effectivement une perte d'espace disque et de temps processeur sur les insertions / mises à jour / suppressions.
Dr.Strangelove

2
Ah! Alors le conseil est mauvais! Nous ne devons PAS toujours indexer nos clés étrangères. Comme l'a souligné @ Dr.Strangelove, il y a des moments où nous ne voulons pas les indexer! Merci beaucoup, docteur!
Bobort

Pourquoi ne sont-ils pas indexés par défaut? Existe-t-il un cas d'utilisation important qui rend cela nécessaire?
Adam Arold

7

Pour a PRIMARY KEY, un index sera créé avec le message suivant:

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

Pour une FOREIGN KEY, la contrainte ne sera pas créé s'il n'y a pas d' index sur la référe ed table.

Un index sur référe ING table n'est pas nécessaire (si désiré), et ne sera donc pas implicitement créé.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.