Quando vuoi la massima velocità di recupero e hai entrambe le colonne nelle condizioni di join o where, MA a volte la colonna a ha una selettività maggiore e talvolta la colonna b ha una selettività maggiore e vuoi capitalizzare questo fatto da un singolo indice.
Inoltre penso che il tuo rapporto tra dimensione dei dati / prestazioni della macchina dovrebbe essere abbastanza alto e allo stesso tempo dovrai (stimare) essere disposto a chiamare qualsiasi miglioramento una necessità (anche se solo di poche percentuali).
Tuttavia, l'esperienza insegna che le cose dipendono da molti fattori; con RDBMS e ambienti applicativi specifici esegui meglio i tuoi benchmark.
EDIT:Ulteriori spiegazioni sugli indici compositi.from wikipedia
:
"L'ordine in cui le colonne sono elencate nella definizione dell'indice è importante. È possibile recuperare un insieme di identificatori di riga utilizzando solo la prima colonna indicizzata. Tuttavia, non è possibile o efficiente (su maggior parte dei database) per recuperare l'insieme di identificatori di riga utilizzando solo la seconda o la successiva colonna indicizzata.
Ad esempio, immagina una rubrica organizzata prima per città, poi per cognome e poi per nome. data la città, puoi facilmente estrarre l'elenco di tutti i numeri di telefono per quella città. Tuttavia, in questa rubrica sarebbe molto noioso trovare tutti i numeri di telefono per un dato cognome. Dovresti cercare all'interno di ogni città sezione per le voci con quel cognome."
Le spiegazioni di Wikipedia sono forse eccessivamente semplificate, ma ti danno l'idea di base (per quanto riguarda le analogie, tieni presente che le rubriche telefoniche di solito hanno indici raggruppati e quello non sarebbe il tuo indice generale del database).
A seconda della dimensione dell'indice rispetto alla dimensione della struttura dei dati rispetto alla memoria disponibile rispetto alla selettività sulla prima colonna dell'indice, potrebbe essere comunque molto meno costoso utilizzare l'indice ordinato in modo errato rispetto alle scansioni delle tabelle.
Ah, ho solo pensato a un'analogia migliore con un esempio che stai cercando Immagina un bel libro di testo, avrebbe un sommario con capitoli e sottocapitoli e il numero delle pagine in cui si trovano (che è un indice non raggruppato che contiene puntatori a record di dati - pagine). Ora immagina che il libro di testo sia sullo standard SQL-92, quindi la maggior parte dei termini in TOC sarebbero termini SQL (mantieni questa ipotesi). Avresti anche un altro indice alla fine del libro che sarebbe elenca tutti i termini interessanti in ordine alfabetico (supponiamo con i nomi dei capitoli principali) e numeri di pagina.
Per domande come "Dimmi tutti i capitoli in cui appare DISTINCT" dovresti usare il secondo indice. (perché la selettività del campo successivo è alta)
Per domande come "Dimmi il numero dei termini che appaiono nel primo capitolo", dovresti utilizzare il sommario
Quindi, per domande come 'È SELECT descritto nel capitolo DML?' potresti usare uno degli indici (perché la selettività di entrambi i campi è alta) Tuttavia se il TOC di DML stesso è lungo 3 pagine e la voce SELECT nell'indice ha solo quindici righe, probabilmente andresti al secondo, e cioè un esempio di quando si beneficia di entrambi gli indici.
Ora, se pensi che sia troppo inverosimile, prendi in considerazione un database della libreria scansionata del congresso. :)
Come ho detto prima, tutta la pianificazione va bene, ma alla fine esegui i tuoi benchmark.
