Indici del database:la rubrica telefonica della tua app

Gli indici del database, spiegati semplicemente: funzionano esattamente come una rubrica telefonica. Invece di leggere ogni pagina per trovare un nome, ci vai direttamente. Senza un indice, il database legge ogni singola riga di una tabella per rispondere a una domanda. Con un indice, una query reale sugli stessi dati è scesa da 2.300 millisecondi a 2,3, mille volte più veloce, perché ha scansionato 47 righe corrispondenti invece di 500.000.

Gli indici sono lo strumento di performance con la leva più alta che toccherai mai, non richiedono alcuna modifica al codice e l'AI si dimentica regolarmente di aggiungerli. Ecco cosa sono, la regola che copre il 90% dei casi e i numeri reali di produzione che mostrano cosa è in gioco.

Indici del database spiegati: che cos'è un indice?

Pensa a come trovi “Gonçalves” in una rubrica telefonica. Non parti da pagina uno leggendo ogni voce: sfrutti il fatto che la rubrica è ordinata, salti vicino alle G e arrivi al nome in pochi secondi. Ora immagina la stessa rubrica con le voci in ordine casuale. Trovare un nome significa leggere l'intero libro, ogni volta, per ogni ricerca.

Quella seconda rubrica è una tabella di database senza indice. Le tabelle memorizzano le righe senza un ordine utile, quindi una domanda come “mostrami le attività di questo cliente” costringe il database a esaminare ogni riga e tenere quelle corrispondenti: una scansione completa. Un indice è la rubrica ordinata che il database mantiene a parte: una copia di ricerca rapida di una colonna (o di più) che gli permette di saltare direttamente alle righe giuste.

La traduzione in termini di esperienza utente: 2,3 secondi sono una pagina che i tuoi clienti guardano caricarsi. 2,3 millisecondi sono istantanei. Stessa query, stessi dati: l'unica differenza è un indice.

La regola: indicizza ogni chiave esterna

Non devi diventare un ingegnere delle performance. Una regola copre la stragrande maggioranza dei casi reali:

Indicizza ogni chiave esterna, e ogni colonna che filtri o ordini di frequente.

Una chiave esterna è qualsiasi colonna che punta a un'altra tabella: il cliente a cui appartiene un'attività, il progetto che una fattura addebita, lo stato che un record porta. In un database ben strutturato (quello che ottieni normalizzando come si deve), queste colonne di riferimento sono ovunque, ed è proprio ciò che il database usa per collegare le tabelle quando risponde alle domande. Ognuna riceve un indice. Nessuna eccezione, nessuna valutazione caso per caso.

Oltre a queste, indicizza le colonne che le tue schermate filtrano e ordinano di continuo: l'organizzazione a cui appartiene ogni riga (la spina dorsale delle app multi-tenant, filtrata praticamente in ogni query), le date di creazione per gli elenchi “dal più recente”, e il timestamp di cancellazione logica che quasi ogni query controlla per nascondere i record eliminati. L'abitudine è una riga per colonna al momento della creazione della tabella, CREATE INDEX idx_tasks_project_id ON tasks(project_id);, ed è un'abitudine che l'AI non manterrà per te: gli schemi generati definiscono regolarmente i riferimenti e saltano gli indici, il che funziona perfettamente in una demo con 50 righe e crolla con 500.000.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Indici compositi: il secondo trucco della rubrica

Una rubrica non è ordinata per una sola cosa: è ordinata per cognome, poi per nome. Questo ti permette di trovare tutti gli “Rossi”, oppure esattamente “Rossi, Mario”. Quello che non può fare è trovare tutti i “Mario” a prescindere dal cognome: per questo torni a leggere l'intero libro.

Un indice composito è la stessa struttura su due o più colonne, e obbedisce alla stessa legge da sinistra a destra. Un indice su (organizzazione, stato) accelera “tutto per questa organizzazione” e “tutto per questa organizzazione con questo stato”, ma non fa nulla per “tutto con questo stato in tutte le organizzazioni”, perché lo stato è il nome, non il cognome.

La conseguenza pratica: l'ordine delle colonne conta. Metti per prima la colonna per cui filtri sempre: in un prodotto multi-tenant, è l'organizzazione. E gli indici compositi hanno un potere in più: se l'ordine dell'indice coincide con l'ordine di ordinamento della query, i risultati escono già ordinati, saltando del tutto il passaggio di ordinamento.

Quando NON indicizzare

Gli indici non sono gratis: ognuno consuma spazio su disco e va aggiornato a ogni scrittura, quindi ogni indice in più rende inserimenti e aggiornamenti un po' più lenti. Quattro situazioni in cui conviene saltarli:

Colonne a due valori. Un flag vero/falso divide la tabella più o meno a metà: saltare a “metà libro” non fa risparmiare niente. Tabelle piccole. Sotto le 1.000 righe circa, leggere l'intera tabella è di fatto istantaneo; la chiave primaria basta. Colonne che non cerchi mai. Solo le colonne che compaiono in filtri, ordinamenti o collegamenti meritano un indice, non le note in testo libero. Colonne che cambiano di continuo in tabelle con molte scritture. Ogni modifica deve aggiornare anche l'indice; in una tabella che viene soprattutto scritta e raramente letta, lo scambio va nel verso sbagliato.

La regola d'oro: ogni indice deve giustificare la propria esistenza con un miglioramento misurabile di una query. Indicizzare “per ogni evenienza” è il modo in cui finisci con scritture lente e disco sprecato.

Numeri reali di produzione

Tre misurazioni reali prima e dopo, ognuna su una schermata comune in un prodotto SaaS:

Ogni riga è la stessa storia: il database ha smesso di leggere tutto e ha iniziato a saltare. E il flusso che le ha prodotte è ripetibile da qualsiasi fondatore: trova la schermata lenta, chiedi al database di spiegare come ha risposto alla query (ogni database ha una funzione “explain”, e chiedere all'AI di interpretarne l'output funziona benissimo), aggiungi l'indice indicato dalla spiegazione, misura di nuovo. Quando il report dice “ha scansionato 500.000 righe per restituirne 20”, hai trovato l'indice mancante.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Come trovo gli indici che mi mancano?

Segui la lentezza. Quando una pagina arranca, prendi la sua query, esegui la funzione explain del tuo database e cerca le scansioni complete della tabella: il report dice letteralmente quante righe sono state lette rispetto a quelle restituite. Anche le dashboard dei database moderni mostrano le query più lente e spesso suggeriscono direttamente l'indice mancante. Incolla qualsiasi cosa nell'AI per un'interpretazione in italiano semplice.

Si possono avere troppi indici?

Sì. Ogni indice tassa ogni scrittura e occupa disco, quindi una tabella con una dozzina di indici speculativi paga costi reali per query ipotetiche. Parti dalla regola (chiavi esterne, organizzazione, filtri comuni), poi aggiungine altri solo quando una query lenta misurata lo richiede, ed elimina gli indici che nessuno usa.

Gli indici velocizzano anche le scritture?

No, anzi, le rallentano leggermente. Un indice accelera la lettura ma va aggiornato a ogni modifica dei dati, quindi le scritture pagano una piccola tassa per indice. Per un tipico prodotto SaaS, che legge molto più di quanto scrive, lo scambio vale ampiamente; solo, non indicizzare colonne che nessuno cerca mai.

L'AI aggiungerà gli indici per me in automatico?

A volte, in modo incostante: dimenticare gli indici sulle chiavi esterne è una delle lacune più comuni negli schemi generati dall'AI, perché la demo funziona benissimo anche senza. Rendilo esplicito: di' all'AI che ogni tabella che crea deve indicizzare le chiavi esterne e le colonne filtrate più spesso, e rivedi lo schema rispetto a quella regola come una checklist.