2010-05-20 16 views
5

Ho alcune domande sulle chiavi primarie composite e la cardinalità delle colonne. Ho cercato sul web, ma non ho trovato nessuna risposta definitiva, quindi ci sto provando di nuovo. Le domande sono:Composito primario e cardinalità

Contesto: tabelle di preparazione OLAP di grandi dimensioni (50M - 500M), non NOSQL, non Columnar. MySQL e DB2

1) L'ordine delle chiavi in ​​un PK è importante?

2) Se la cardinalità delle colonne varia notevolmente, è necessario utilizzarla per prima. Ad esempio, se ho CLIENT/CAMPAIGN/PROGRAM in cui CLIENT è altamente cardinale, CAMPAIGN è moderato, PROGRAM è quasi come un indice bitmap, quale ordine è il migliore?

3) Quale ordine è la migliore per Join, se v'è una clausola Where e quando non v'è la clausola Dove (per le viste)

Grazie in anticipo.

risposta

2

1) L'ordine delle chiavi in ​​un PK è importante?

Sì, cambia l'ordine del record per l'indice utilizzato per controllare lo PRIMARY KEY.

2) Se la cardinalità delle colonne varia notevolmente, è necessario utilizzarla per prima. Ad esempio, se ho CLIENT/CAMPAIGN/PROGRAM in cui CLIENT è altamente cardinale, CAMPAIGN è moderato, PROGRAM è quasi come un indice bitmap, quale ordine è il migliore?

Per le query selezionate, questo dipende totalmente dalle query che si intende utilizzare. Se stai cercando tutte e tre le colonne contemporaneamente, l'ordine non è importante; se stai cercando due o una colonna, dovrebbero essere in testa all'indice.

Per gli inserti, è preferibile far corrispondere la colonna principale all'ordine in cui sono stati inseriti i record.

3) Quale ordine è la migliore per Join, se v'è una clausola Where e quando non v'è la clausola Dove (per le viste)

Ancora una volta, questo dipende dalla clausola di WHERE.

+0

Grazie, quindi se mi unisco solo sul Cliente e Campagna, dovrei unirmi alla campagna (basso cardinalità) prima poi CLIENT (maggiore cardinalità) –

+0

@srini: non c'è un "prima" e " ultimo "in un join, ti unisci sempre su entrambe le colonne allo stesso tempo. Queste colonne dovrebbero essere in testa all'indice '(client, campagna, programma)' affinchè l'unione sia efficiente. – Quassnoi

+0

Spiacente, intendevo l'ordine per la clausola WHERE .. –

3

Hai "MySQL e DB2". Questa risposta è per DB2, MySQL non ha nulla di tutto ciò.

Sì, certo che è logico, ma l'ottimizzatore prende molto di più di quello in considerazione.

In genere, l'ordine delle colonne nella clausola WHERE (join) non importa (e non dovrebbe).

Tuttavia, ci sono due voci relative all'ordine dei predicati che possono essere il motivo della tua domanda.

  1. Ciò che conta, è l'ordine delle colonne nell'indice, contro la quale la clausola WHERE viene elaborato. Sì, è meglio specificare le colonne nell'ordine di cardinalità più alta al più basso.Ciò consente all'ottimizzatore di scegliere come target una gamma più piccola di righe.

    • E lungo quelle linee non si preoccupano di implementare gli indici per colonne a cardinalità a colonna singola, bassa (inutili). Se l'indice è corretto, verrà usato più spesso.
      .
  2. L'ordine delle tabelle essere uniti (non colonne nel join) questioni molto, è probabilmente la considerazione più importante. In effetti, Join Transitive Closure è automatico e l'ottimizzatore valuta tutti i possibili ordini di join e sceglie ciò che ritiene essere il migliore, in base alle statistiche (motivo per cui UPDATE STATS è così importante).

    Indipendentemente dal numero di righe nelle tabelle, se si stanno unendo 100 righe da table_A su un indice non valido con 1,000,000 righe in table_B su un indice valido, si desidera l'ordine A: B, non B: A. Se stai ricevendo meno del numero massimo di IOPS, potresti voler fare qualcosa al riguardo.

    La corretta sequenza di fasi è, non sorprende:

    • controllo che l'indice è corretta secondo (1). Non aggiungere semplicemente un altro indice, correggere quelli che hai.

    • controllare che le statistiche aggiornamento viene eseguito regolarmente

    • Cercare sempre il funzionamento di default del ottimizzatore prima. Imposta le statistiche e misura gli I/O. Utilizza set di valori rappresentativi (che l'utente utilizzerà in produzione).

    • controllare il piano di lavoro per assicurarsi che il codice sia corretto. Ovviamente questo identificherà anche l'ordine di join scelto.

    • se la prestazione non è abbastanza buono, e si crede che l'ordine il join scelto dal ottimizzatore per quei set di valori è sub-ottimale, SET JTC OFF (sintassi dipende dalla vostra versione di DB2), quindi specificare l'ordine che si desidera nella clausola WHERE. Misura I/O. Utilizzare set rappresentativi

    • formare un parere. Scegli quale sia la migliore prestazione complessiva. Non sintonizzare mai per singole query.

Problemi correlati