Ciao, e benvenuto nella sesta puntata della cinquantaquattresima stagione. Oggi torniamo su un'idea che avevamo incontrato con Postgres, gli indici, ma la guardiamo da un'angolazione che in MySQL, con il suo motore moderno, è particolare e piena di conseguenze pratiche. Oggi capiamo come si trova in fretta, e perché in MySQL i dati vivono dentro il loro indice.
Ripartiamo dall'indice, in breve, perché è la base. Un indice serve a trovare una cosa senza doverle leggere tutte. Senza indice, cercare una riga tra milioni vuol dire scorrerle una a una, lentissimo. Con un indice, una struttura ordinata a parte, salti dritto a quella giusta, come usando l'indice analitico in fondo a un libro. Questo vale per ogni base di dati, e ne parlammo per Postgres. Oggi vediamo una scelta di progetto di MySQL che rende gli indici, qui, un po' speciali.
Voglio darti l'idea particolare, perché è il cuore della puntata. In MySQL, con il motore moderno, c'è una cosa che chiamano chiave primaria: un identificatore unico per ogni riga, il suo nome proprio, di solito un numero. E qui arriva la sorpresa: le righe della tabella non sono conservate a parte, in un mucchio qualsiasi, con l'indice di fianco. No: le righe vivono fisicamente dentro l'indice della chiave primaria, ordinate secondo essa. In altre parole, l'indice principale non punta ai dati: l'indice principale è i dati. La tabella e il suo indice per chiave primaria sono la stessa cosa.
Voglio darti l'immagine che rende chiara questa idea, perché è netta. Pensa a un grande schedario di cartelline. In molti sistemi, le cartelline stanno buttate in un cassetto in ordine sparso, e a fianco tieni un elenco ordinato che, per ogni nome, ti dice in quale punto del cassetto guardare. In MySQL col motore moderno, invece, le cartelline stesse sono tenute nel cassetto già ordinate per numero identificativo. Non c'è un elenco separato che rimanda al cassetto: il cassetto è già l'elenco, e trovare per numero vuol dire aprire il cassetto al punto giusto e la cartellina è lì, subito, con dentro già tutto.
Voglio dirti la prima conseguenza, perché è utile. Il vantaggio è che cercare per chiave primaria è velocissimo: arrivi all'indice giusto e i dati sono già lì, non devi fare un secondo salto per andarli a prendere altrove. Per l'operazione più comune di tutte, trovare una riga dal suo identificatore, è l'ideale. Ma questa scelta ha conseguenze anche sugli altri indici, quelli che crei sulle altre colonne, per cercare, per esempio, per nome o per data. E qui la faccenda si fa sottile, perché ciò che è comodo per una ricerca può costare per un'altra, e vale la pena capirlo bene prima di riempire una tabella di indici a caso.
Voglio dirti la seconda conseguenza, perché è meno ovvia. Gli altri indici, quelli secondari, non contengono la posizione fisica della riga: contengono la chiave primaria di quella riga. Cioè: cerchi per nome, l'indice sul nome ti dà la chiave primaria, e poi con quella si va a pescare la riga vera nell'indice principale. È un doppio passaggio. Ne segue una regola d'oro pratica: la chiave primaria dovrebbe essere piccola e ordinata, perché è ripetuta dentro ogni altro indice. Se scegli una chiave primaria enorme o casuale, appesantisci ogni indice della tabella e rallenti le scritture. Una decisione apparentemente minuscola, con effetti ovunque. È il tipo di dettaglio che nessuno ti spiega finché il sito non rallenta senza un motivo apparente, e allora scopri che la radice di tutto era il nome proprio scelto per le righe, anni prima, da qualcuno che non sapeva quanto pesasse quella scelta.
Voglio trarre la lezione generale, perché va oltre MySQL. La lezione è che le scelte di come i dati sono fisicamente organizzati sul disco, invisibili quando tutto va bene, decidono le prestazioni quando i numeri crescono. In MySQL, capire che la tabella vive dentro la chiave primaria ti spiega perché certe cose volano e altre arrancano, e perché la scelta della chiave primaria, che sembra un dettaglio noioso, è in realtà una delle decisioni più importanti che prendi. È di nuovo il nostro filo: il modello sotto la magia. Sapere come le cose sono davvero disposte sotto è ciò che separa chi indovina da chi capisce.
Per oggi ci fermiamo qui. Abbiamo visto gli indici in salsa MySQL. L'indice serve a trovare senza leggere tutto, come l'indice di un libro. Ma con il motore moderno c'è una particolarità: le righe non stanno separate con l'indice di fianco, vivono fisicamente dentro l'indice della chiave primaria, ordinate per essa. L'indice principale è i dati. Come uno schedario in cui le cartelline stesse sono già ordinate per numero. Cercare per chiave primaria è velocissimo, i dati sono già lì. Ma gli altri indici contengono la chiave primaria, non la posizione, quindi la chiave primaria dev'essere piccola e ordinata, o appesantisci tutto. La lezione: l'organizzazione fisica dei dati, invisibile, decide le prestazioni. Nella prossima puntata: quando il buon senso tace, la storia della permissività. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.