Non sono d'accordo con alcune delle risposte a questa domanda.
Esiste un numero eccessivo di indici?
Naturalmente. Non creare indici non utilizzati da nessuna delle tue query. Non creare indici ridondanti. Usa strumenti come pt-duplicate-key-checker e pt-index-usage per aiutarti a scoprire gli indici che non ti servono.
Che accelereranno gli indici?
- ricerca condizioni nella clausola WHERE.
- Condizioni di adesione.
- Alcuni casi di ORDER BY.
- Alcuni casi di GROUP BY.
- Vincoli UNICI.
- vincoli FOREIGN KEY.
- ricerca FULLTEXT.
Altre risposte hanno avvisato che INSERIRE/AGGIORNA/CANCELLA sono più lenti più gli indici si hanno. È vero, ma considera che molti usi di UPDATE e DELETE hanno anche clausole WHERE e anche in MySQL, UPDATE e DELETE supportano JOINs. Gli indici possono beneficiare queste query più che compensare il sovraccarico di aggiornamento degli indici.
Inoltre, InnoDB blocca le righe interessate da un UPDATE o DELETE. Chiamano questo blocco a livello di riga, ma è davvero un blocco a livello di indice. Se non c'è un indice per restringere la ricerca, InnoDB deve bloccare molte più righe rispetto alla riga specifica che stai modificando. Può anche bloccare tutte le le righe nella tabella. Questi blocchi bloccano le modifiche apportate da altri client, anche se non sono logicamente in conflitto.
Quando è consigliabile aggiungere un indice?
Se si sa che è necessario eseguire una query che trarrebbe vantaggio da un indice in uno dei casi precedenti.
Quando è una cattiva idea aggiungere un indice?
Se l'indice è un prefisso di sinistra di un altro indice esistente, o l'indice non aiuta nessuna delle query che è necessario eseguire.
Pro e contro di più indici vs indici multi-colonna?
In alcuni casi, MySQL può effettuare index-merge optimization, e sia l'unione o si intersecano i risultati di ricerche di indice indipendenti. Ma offre prestazioni migliori per definire un singolo indice in modo che non sia necessario eseguire l'unione con gli indici.
Per uno dei miei clienti di consulenza, ho definito un indice multi-colonna su una tabella molti-a-molti in cui non c'era alcun indice e ho migliorato la loro query di join di un fattore di 94 milioni!
La progettazione degli indici corretti è un processo complesso, basato su , le query necessarie per ottimizzare. Non devi fare regole generiche come "indicizza tutto" o "non indicizzare nulla per evitare di rallentare gli aggiornamenti".
Vedere anche la mia presentazione How to Design Indexes, Really.
wow, questa informazione è davvero incredibilmente ben strutturata e molto utile! E il più utile per me è che un indice su cui viene applicata una funzione è inutile ... grazie per questa risposta! – Chris
@OMG, Per quanto riguarda l'ultimo paragrafo, è possibile utilizzare più di un indice per 'select' a causa dell'indice di unione. http://www.percona.com/blog/2012/12/14/the-optimization-that-often-isnt-index-merge-intersection/ – Pacerier
-1 per aver detto (1) accelera solo "SELECT", velocizza le query SELECT, UPDATE e DELETE, a condizione che gli indici siano creati correttamente in base alle condizioni "WHERE", ma richiede l'aggiornamento degli indici sulla manipolazione dei dati, il che significa che solo le query INSERT saranno più lente (in tutti i casi) di senza indici e (2) per dire che MySQL può usare solo un indice alla volta. –