Postgres e índices en claves extranjeras y claves primarias


Respuestas:


406

PostgreSQL crea automáticamente índices en claves primarias y restricciones únicas, pero no en el lado de referencia de las relaciones de clave externa.

Cuando Pg crea un índice implícito, emitirá un NOTICEmensaje de nivel que puede ver psqly / o los registros del sistema, para que pueda ver cuándo sucede. Los índices creados automáticamente también son visibles en la \dsalida de una tabla.

La documentación sobre índices únicos dice:

PostgreSQL crea automáticamente un índice para cada restricción única y restricción de clave principal para imponer la unicidad. Por lo tanto, no es necesario crear un índice explícitamente para columnas de clave primaria.

y la documentación sobre restricciones dice:

Dado que un BORRADO de una fila de la tabla referenciada o una ACTUALIZACIÓN de una columna referenciada requerirá un análisis de la tabla de referencia para las filas que coinciden con el valor anterior, a menudo es una buena idea indexar las columnas de referencia. Como esto no siempre es necesario y hay muchas opciones disponibles sobre cómo indexar, la declaración de una restricción de clave externa no crea automáticamente un índice en las columnas de referencia.

Por lo tanto, debe crear índices en claves foráneas usted mismo si los desea.

Tenga en cuenta que si usa claves externas primarias, como 2 FK como PK en una tabla de M a N, tendrá un índice en la PK y probablemente no necesite crear ningún índice adicional.

Si bien generalmente es una buena idea crear un índice en (o incluir) las columnas de clave externa del lado de referencia, no es obligatorio. Cada índice que agrega ralentiza ligeramente las operaciones de DML, por lo que paga un costo de rendimiento en cada INSERT, UPDATEo DELETE. Si el índice se usa raramente, puede que no valga la pena tenerlo.


26
Espero que esta edición esté bien; He agregado enlaces a la documentación relevante, una cita que hace completamente explícito que el lado de referencia de las relaciones FK no produce un índice implícito, que muestra cómo ver los índices en psql, reformuló el primer par para mayor claridad y agregué un tenga en cuenta que los índices no son gratuitos, por lo que no siempre es correcto agregarlos.
Craig Ringer el

1
@CraigRinger, ¿cómo determina si el beneficio de un índice supera su costo? ¿Perfilo las pruebas unitarias antes / después de agregar un índice y verifico una ganancia de rendimiento general? ¿O hay un mejor camino?
Gili

2
@Gili Ese es un tema para una pregunta por separado dba.stackexchange.com.
Craig Ringer

34

Si desea enumerar los índices de todas las tablas en su esquema (s) de su programa, toda la información está disponible en el catálogo:

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 desea profundizar más (como columnas y pedidos), debe mirar pg_catalog.pg_index. El uso psql -E [dbname]es útil para descubrir cómo consultar el catálogo.


44
+1 porque el uso de pg_catalog y psql -E es realmente muy útil
Ghislain Leveque

"Como referencia \ditambién se enumerarán todos los índices en la base de datos". (comentario copiado de otra respuesta, se aplica aquí también)
Risadinha

33

Esta consulta enumerará los índices que faltan en las claves externas , fuente original .

Editar : Tenga en cuenta que no verificará tablas pequeñas (menos de 9 MB) y algunos otros casos. Ver WHEREdeclaración final .

-- 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;

77
No parece funcionar Devuelve 0 filas cuando sé que tengo columnas sin índices que hacen referencia a tablas de dominio.
juanitogan

66
@juanitogan Observe las wherecláusulas: entre otras, solo tiene en cuenta las tablas cuyo tamaño es superior a 9 MB.
Matthias

@Matthias - Ah, lo tengo. Gracias. Sí, obviamente no me tomé el tiempo de leer el código. No fue lo suficientemente crítico como para molestarse. El OP podría haber mencionado las limitaciones. Tal vez lo revise de nuevo alguna vez.
juanitogan

@SergeyB parece dar falso positivo en las columnas a las que se hace referencia con una restricción de clave principal, por lo que automáticamente tiene un índice, pero la consulta aún las marca.
Debasish Mitra

21

Sí, para claves primarias, no, para claves externas (más en los documentos ).

\d <table_name>

en "psql" muestra una descripción de una tabla que incluye todos sus índices.


11
Para referencia \ di también enumerará todos los índices en la base de datos.
Daemin

14

Me encanta cómo se explica esto en el artículo Características de rendimiento interesantes de EclipseLink 2.5

Indización de claves extranjeras

La primera característica es la indexación automática de claves foráneas. La mayoría de las personas asume incorrectamente que las bases de datos indexan claves foráneas por defecto. Bueno, ellos no. Las claves primarias se indexan automáticamente, pero las claves externas no. Esto significa que cualquier consulta basada en la clave externa realizará escaneos completos de la tabla. Esta es cualquier relación OneToMany , ManyToMany o ElementCollection , así como muchas relaciones OneToOne , y la mayoría de las consultas sobre cualquier relación que implique uniones o comparaciones de objetos . Este puede ser un problema importante de rendimiento, y siempre debe indexar los campos de claves externas.


55
Si siempre debemos indexar nuestros campos de claves externas, ¿por qué los motores de bases de datos ya no lo hacen? Me parece que hay más en esto de lo que parece.
Bobort

3
@Bobort Dado que agregar índice incurre en una penalización de rendimiento en todas las inserciones, actualizaciones y eliminaciones, y muchas claves externas realmente podrían sumar en este caso. Es por eso que este comportamiento es opcional, supongo: el desarrollador debe hacer una elección consciente en este asunto. También podría haber casos en los que se utiliza una clave externa para hacer cumplir la integridad de los datos, pero no se consulta con frecuencia ni se consulta en absoluto; en este caso, la penalización de rendimiento del índice no sería nada
Dr.Strangelove

3
También hay casos difíciles con índices compuestos, ya que se aplican de izquierda a derecha: es decir, el índice compuesto en [user_id, article_id] en la tabla de comentarios cubriría de manera efectiva tanto la consulta de TODOS los comentarios por usuario (por ejemplo, para mostrar el registro de comentarios agregados en el sitio web) como la obtención de todos comentarios realizados por este usuario para un artículo específico. Agregar un índice separado en user_id en este caso es efectivamente una pérdida de espacio en disco y tiempo de CPU en inserciones / actualizaciones / eliminaciones.
Dr.Strangelove

2
¡Ajá! ¡Entonces el consejo es pobre! NO siempre debemos indexar nuestras claves foráneas. Como @ Dr.Strangelove ha señalado, en realidad hay momentos en que no queremos indexarlos. Muchas gracias, Dr.!
Bobort

¿Por qué no están indexados por defecto? ¿Existe un caso de uso importante que lo haga necesario?
Adam Arold

7

Para a PRIMARY KEY, se creará un índice con el siguiente mensaje:

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

Para una FOREIGN KEY, la restricción no se creará si no existe un índice en la referenc ed mesa.

No se requiere un índice en la tabla de referencia (aunque se desee) y, por lo tanto, no se creará implícitamente.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.