Dovresti assolutamente dedicare un po' di tempo alla lettura dell'indicizzazione, c'è molto scritto a riguardo ed è importante capire cosa sta succedendo.
In linea di massima, un indice impone un ordinamento alle righe di una tabella.
Per semplicità, immagina che una tabella sia solo un grande file CSV. Ogni volta che viene inserita una riga, viene inserita alla fine . Quindi l'ordinamento "naturale" della tabella è proprio l'ordine in cui sono state inserite le righe.
Immagina di avere quel file CSV caricato in un'applicazione per fogli di calcolo molto rudimentale. Tutto ciò che fa questo foglio di calcolo è visualizzare i dati e numerare le righe in ordine sequenziale.
Ora immagina di dover trovare tutte le righe che hanno un valore "M" nella terza colonna. Dato quello che hai a disposizione, hai solo un'opzione. Esegui la scansione della tabella controllando il valore della terza colonna per ogni riga. Se hai molte righe, questo metodo (una "scansione tabella") può richiedere molto tempo!
Ora immagina di avere un indice oltre a questa tabella. Questo particolare indice è l'indice dei valori nella terza colonna. L'indice elenca tutti i valori della terza colonna, in un ordine significativo (diciamo, in ordine alfabetico) e per ciascuno di essi, fornisce un elenco di numeri di riga in cui appare quel valore.
Ora hai una buona strategia per trovare tutte le righe in cui il valore della terza colonna è "M". Ad esempio, puoi eseguire una ricerca binaria ! Mentre la scansione della tabella richiede di guardare N righe (dove N è il numero di righe), la ricerca binaria richiede solo di guardare le voci dell'indice log-n, nel peggiore dei casi. Wow, è sicuramente molto più semplice!
Ovviamente, se hai questo indice e stai aggiungendo righe alla tabella (alla fine, poiché è così che funziona la nostra tabella concettuale), devi aggiornare l'indice ogni volta. Quindi fai un po' più di lavoro mentre scrivi nuove righe, ma risparmi un sacco di tempo quando cerchi qualcosa.
Quindi, in generale, l'indicizzazione crea un compromesso tra efficienza di lettura ed efficienza di scrittura. Senza indici, gli inserimenti possono essere molto veloci:il motore di database aggiunge semplicemente una riga alla tabella. Quando aggiungi gli indici, il motore deve aggiornare ogni indice durante l'esecuzione dell'inserimento.
D'altra parte, le letture diventano molto più veloci.
Se tutto va bene, questo copre le tue prime due domande (come altri hanno risposto:devi trovare il giusto equilibrio).
Il tuo terzo scenario è un po' più complicato. Se stai usando LIKE, i motori di indicizzazione in genere ti aiutano con la velocità di lettura fino al primo "%". In altre parole, se stai SELEZIONANDO la colonna WHERE COME 'foo%bar%', il database utilizzerà l'indice per trovare tutte le righe in cui la colonna inizia con "foo", quindi dovrai scansionare quel set di righe intermedio per trovare il sottoinsieme che contiene "bar". SELECT ... WHERE la colonna LIKE '%bar%' non può utilizzare l'indice. Spero che tu possa capire perché.
Infine, devi iniziare a pensare agli indici su più di una colonna. Il concetto è lo stesso e si comporta in modo simile alla roba LIKE -- essenzialmente, se hai un indice su (a, b, c), il motore continuerà a usare l'indice da sinistra a destra nel miglior modo possibile. Quindi una ricerca sulla colonna a potrebbe utilizzare l'indice (a,b,c), come farebbe una su (a,b). Tuttavia, il motore dovrebbe eseguire una scansione completa della tabella se stavi cercando WHERE b=5 AND c=1)
Spero che questo aiuti a fare un po' di luce, ma devo ribadire che è meglio passare qualche ora a cercare buoni articoli che spieghino queste cose in profondità. È anche una buona idea leggere la documentazione del tuo particolare server di database. Il modo in cui gli indici vengono implementati e utilizzati dai pianificatori di query può variare notevolmente.
