La quantità di indicizzazione e la linea di fare troppo dipenderanno da molti fattori. Su tavoli piccoli come il tuo tavolo "categorie" di solito non vuoi o hai bisogno di un indice e può effettivamente danneggiare le prestazioni. Il motivo è che ci vuole I/O (cioè tempo) per leggere un indice e quindi più I/O e tempo per recuperare i record associati alle righe corrispondenti. Un'eccezione è quando esegui query solo sulle colonne contenute nell'indice.
Nel tuo esempio stai recuperando tutte le colonne e con solo 22 righe e potrebbe essere più veloce eseguire semplicemente una scansione della tabella e ordinarle invece di usare l'indice. L'ottimizzatore potrebbe/dovrebbe farlo e ignorare l'indice. In tal caso, l'indice sta solo occupando spazio senza alcun vantaggio. Se si accede spesso alla tabella "categories", potresti prendere in considerazione l'idea di bloccarla in memoria in modo che il server db la mantenga accessibile senza dover accedere continuamente al disco.
Quando si aggiungono indici è necessario bilanciare lo spazio su disco, le prestazioni delle query e le prestazioni di aggiornamento e inserimento nelle tabelle. Puoi cavartela con più indici su tabelle che sono statiche e non cambiano molto rispetto alle tabelle con milioni di aggiornamenti al giorno. A quel punto inizierai a sentire gli effetti del mantenimento dell'indice. Ciò che è accettabile nel tuo ambiente è e può essere determinato solo da te e dalla tua organizzazione.
Quando esegui l'analisi, assicurati di generare/aggiornare la tabella e le statistiche dell'indice in modo da poter essere certo di calcoli accurati.
