Index su un tavolo è necessario eseguire la scansione completamente in ogni caso? (MySQL)

Question

Sono abbastanza perplesso qui.

Ho 2 tavoli e ho lasciato entrare i primi (circa 500k record) con il secondo (circa 2,2 milioni di record) al fine di scoprire quali documenti sono in prima e non la seconda. (Tipico "b.attribute è nullo" dialogo)

Perché (come) è possibile che un indice è utilizzato sulla prima tavola? E 'intenzione di passare attraverso registrare ogni nella prima tabella in ogni caso, ma quando provo a farlo aderire, senza alcun indice (o chiave primaria .. nessuno necessaria perché tutto questo è solo ETL) sulla prima tabella, la scansione.

utilizzando InnoDB, tra l'altro.

Aiuto?

EDIT: il 2 ° tavolo è indicizzato. Il primo non è stato.

Answer 1

Non ho idea se questo è ciò che sta accadendo, ma sarebbe, in teoria, essere possibile (a seconda della query reale) per il motore di database di essere la scansione l'indice per la tabella di sinistra piuttosto che la tabella stessa. Si potrebbe costruire i dati chiave necessari per questo. Se la scansione l'indice era più veloce di scansione della tabella, che potrebbe spiegare la differenza di velocità.

Answer 2

Questo dovrebbe far luce su di esso: http: //dev.mysql.com/doc/refman/5.5/en/innodb-index-types.html

In breve: tavoli Tutto InnoDB hanno il cosiddetto 'indice cluster' (anche se nessun indice esplicito è definito nella tabella, InnoDB crea automaticamente), in cui le righe effettive vengono memorizzati.

Answer 3

Lo scopo dell'indice primario è mettere le cose in ordine di classificare e la creazione di un grande albero (almeno in SQL Server). B-tree, se per essere più precisi. Ciò significa che la chiave di ogni record appartiene ad un certo posto (o secchio) nella struttura.

Quindi, perché l'aggiunta di una chiave per la prima tabella aiuta ad accelerare la query? La ragione è che, quando viene eseguita la query, la prima tabella è essere ordinata dal tavolo secondo è già risolto grazie alla presenza di una chiave primaria. Ciò è dovuto al semplice fatto che il confronto due liste ordinate è molto più veloce di fare ricerca binaria per ogni elemento. In questo caso, poiché non v'è alcun indice, ordinamento richiede tempo.

Tra l'altro, non essere confuso con quello che dico. Non è davvero confrontando le liste, ma più la potatura dell'albero dell'indice sulla foto qui sopra, ad esempio, se T1 ha K1, K2, K3 e K1 possono essere trovati in secondo secchio sulla foto allora non c'è bisogno di controllare in primo bucket per il resto delle chiavi.

Answer 4

MySQL non ha hash join.