Yabancı Anahtarlar ve Birincil Anahtarlar Üzerine Postgres ve Dizinler


344

Postgres otomatik olarak Yabancı Anahtarlara ve Birincil Anahtarlara dizinler ekliyor mu? Nasıl söyleyebilirim? Bir tablodaki tüm dizinleri döndürecek bir komut var mı?

Yanıtlar:


406

PostgreSQL otomatik olarak birincil anahtarlarda ve benzersiz kısıtlamalarda dizin oluşturur, ancak yabancı anahtar ilişkilerinin referans tarafında değil.

Pg örtük bir dizin oluşturduğunda NOTICE, görebileceğiniz psqlve / veya sistem günlüklerinde görebileceğiniz bir düzeyli mesaj yayar , böylece ne zaman gerçekleştiğini görebilirsiniz. Otomatik olarak oluşturulan dizinler \dbir tablo için çıktıda da görülebilir .

Benzersiz endeksleri üzerinde belgelerine diyor:

PostgreSQL, benzersizliği zorlamak için her benzersiz kısıtlama ve birincil anahtar kısıtlaması için otomatik olarak bir dizin oluşturur. Bu nedenle, birincil anahtar sütunları için açıkça bir dizin oluşturmak gerekli değildir.

ve kısıtlamalarla ilgili belgeler şunları söylüyor:

Başvurulan tablodan bir satırın DELETE değeri veya başvurulan bir sütunun UPDATE değeri, eski değerle eşleşen satırlar için başvuru tablosunun taranmasını gerektireceğinden, başvuru sütunlarını dizine eklemek genellikle iyi bir fikirdir. Bu her zaman gerekli olmadığından ve nasıl indeksleneceğine dair birçok seçenek olduğundan, yabancı anahtar kısıtlamasının bildirilmesi, referans sütunlarında otomatik olarak bir dizin oluşturmaz.

Bu nedenle, isterseniz yabancı anahtarlar üzerinde dizinler oluşturmanız gerekir.

Bir M-N tablosunda PK olarak 2 FK gibi birincil-yabancı anahtarlar kullanırsanız, PK'da bir dizininizin olacağını ve muhtemelen fazladan dizin oluşturmanıza gerek olmadığını unutmayın.

Referans tarafı yabancı anahtar sütunlarınızda bir dizin oluşturmak (veya dahil etmek) genellikle iyi bir fikir olsa da, gerekli değildir. Her endeks Eğer her bir performans maliyeti ödersiniz bir yavaşlatır aşağı hafifçe işlemleri DML eklemek INSERT, UPDATEya da DELETE. Endeks nadiren kullanılırsa, sahip olmaya değmeyebilir.


26
Umarım bu düzenleme iyidir; İlgili belgelere bağlantılar ekledim, FK ilişkilerinin referans tarafının örtük bir dizin üretmediğini açıkça belirten bir teklif ekledim, psql'deki dizinleri nasıl göreceğimizi gösterdim, netlik için 1. par'ı yeniden ifade etti ve bir dizinlerin ücretsiz olmadığını unutmayın, bu nedenle bunları eklemek her zaman doğru değildir.
Craig Ringer

1
@CraigRinger, bir endeksin faydasının maliyetini aşıp aşmadığını nasıl belirlersiniz? Bir endeks eklemeden önce / sonra birim testlerini profilleştirip genel performans kazancını kontrol ediyor muyum? Yoksa daha iyi bir yol var mı?
Gili

2
@Gili Bu ayrı bir dba.stackexchange.com sorusunun konusu.
Craig Ringer

34

Programınızdan şemalarınızdaki tüm tabloların dizinlerini listelemek istiyorsanız, tüm bilgiler katalogda bulunmaktadır:

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

Daha fazla bilgi edinmek istiyorsanız (sütunlar ve sipariş gibi), pg_catalog.pg_index'e bakmanız gerekir. psql -E [dbname]Kataloğu nasıl sorgulayacağınızı bulmak için kullanmak kullanışlı olur.


4
+1 çünkü pg_catalog ve psql -E kullanımı gerçekten çok yararlı
Ghislain Leveque

"Başvuru için \diayrıca veritabanındaki tüm dizinleri listeler." (yorum diğer cevaptan kopyalandı, burada da geçerlidir)
Risadinha

33

Bu sorgu edecek yabancı anahtarları eksik dizinleri listelemek , orijinal kaynağından .

Düzenleme : Küçük tabloları (9 MB'den az) ve diğer bazı durumları denetlemeyeceğini unutmayın. Son WHEREaçıklamaya bakınız .

-- 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
Çalışmıyor gibi görünüyor. Etki alanı tablolarına başvuran dizinleri olmayan sütunları olduğunu bildiğimde 0 satır döndürür.
juanitogan

6
@juanitogan Cümleleri izleyin where: Diğerlerinin yanı sıra, sadece 9 MB'den büyük olan tabloları dikkate alır.
Matthias

@Matthias - Ah, anladım. Teşekkürler. Evet, kodu okumak için zaman ayırmadım. Rahatsız edecek kadar kritik değildi. OP sınırlamalardan bahsedebilirdi. Belki bir ara tekrar kontrol edeceğim.
juanitogan

@SergeyB, üzerinde birincil anahtar kısıtlaması bulunan ve bu nedenle otomatik olarak bir dizine sahip olan referans sütunlara yanlış pozitif veriyor gibi görünüyor, ancak sorgu hala onları işaretliyor.
Debasish Mitra

21

Evet - birincil anahtarlar için, hayır - yabancı anahtarlar için ( dokümanlarda daha fazlası ).

\d <table_name>

içinde "psql'in" gösterileri tüm dizinleri içeren bir tablonun bir açıklaması.


11
Referans \ di ayrıca veritabanındaki tüm dizinleri listeler.
Daemin

14

EclipseLink 2.5'in serin performans özellikleri makalesinde nasıl açıklandığını seviyorum

Yabancı Anahtarları Dizinleme

İlk özellik yabancı anahtarların otomatik indekslenmesidir. Çoğu kişi, veritabanlarının varsayılan olarak yabancı anahtarları endekslediğini yanlış bir şekilde varsayar. Onlar bilmiyorlar. Birincil anahtarlar otomatik olarak dizine eklenir, ancak yabancı anahtarlar oluşturulmaz. Bu, yabancı anahtara dayalı herhangi bir sorgunun tam tablo taramaları yapacağını gösterir. Bu, herhangi bir OneToMany , ManyToMany veya ElementCollection ilişkisinin yanı sıra birçok OneToOne ilişkisidir ve birleştirme veya nesne karşılaştırmalarını içeren herhangi bir ilişki hakkındaki çoğu sorudur . Bu önemli bir sorun olabilir ve her zaman yabancı anahtar alanlarınızı dizine eklemelisiniz.


5
Biz olursa her zaman indeksi yabancı anahtarları alanları, neden veritabanı motorları zaten yapmıyorsun? Bana öyle geliyor ki, gözle görülenden daha fazlası var.
Bobort

3
@Bobort İndeks eklemek tüm ekler, güncellemeler ve silme işlemlerinde performans cezası verdiğinden ve bu durumda birçok yabancı anahtar gerçekten toplanabilir. Bu yüzden bu davranış tercih edilir sanırım - geliştirici bu konuda bilinçli bir seçim yapmalıdır. Veri bütünlüğünü uygulamak için yabancı anahtarın kullanıldığı, ancak sık sık sorgulanmadığı veya hiç sorgulanmadığı durumlar da olabilir - bu durumda, dizinin performans cezası hiçbir
işe

3
Bileşik indeksleri olan zor durumlar da vardır, çünkü bunlar soldan sağa uygulanır: yani yorumlar tablosundaki [user_id, article_id] üzerindeki bileşik dizin, hem TÜM yorumları kullanıcı tarafından sorgulamayı etkin bir şekilde kapsayabilir (örneğin, web sitesinde toplu yorum günlüğünü göstermek için) ve tümünü getirir belirli bir makale için bu kullanıcı tarafından yapılan yorumlar. Bu durumda user_id öğesine ayrı bir dizin eklemek etkili bir şekilde disk alanı ve ekleme / güncelleme / silme işlemlerinde zaman kaybıdır.
Dr.Strangelove

2
Aha! O zaman tavsiye kötü! Yabancı anahtarlarımızı her zaman endekslememeliyiz. @ Dr.Strangelove'un işaret ettiği gibi, aslında onları endekslemek istemediğimiz zamanlar var! Çok teşekkür ederim, Dr.
Bobort

Neden varsayılan olarak dizine eklenmez? Bunu gerekli kılan önemli bir kullanım durumu var mı?
Adam Arold

7

A için PRIMARY KEY, aşağıdaki iletiyle bir dizin oluşturulur:

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

Bir İçin FOREIGN KEYreferenc üzerinde hiçbir dizin varsa, kısıtlama oluşturulmayacak ed masaya.

Referenc üzerine bir indeks ing tablosunun (istenen gerçi) gerekli değildir ve bu nedenle örtülü olarak oluşturulmaz.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.