Progettazione dello schema prima: app più veloci rispetto all'ottimizzazione precoce delle query

Schema vs ottimizzazione delle query: cosa intendiamo

Quando un'app sembra lenta, il primo istinto è spesso “sistemare la SQL”. Questo ha senso: una singola query è visibile, misurabile e facile da incolpare. Puoi eseguire EXPLAIN, aggiungere un indice, modificare un JOIN e a volte ottenere un miglioramento immediato.

Ma nelle prime fasi di vita di un prodotto, i problemi di velocità possono dipendere tanto dalla forma dei dati quanto dal testo specifico della query. Se lo schema ti costringe a combattere contro il database, l'ottimizzazione delle query diventa un gioco del gatto col topo.

Progettazione dello schema (in parole semplici)

La progettazione dello schema è come organizzi i tuoi dati: tabelle, colonne, relazioni e regole. Include decisioni come:

• Quali “cose” meritano una loro tabella (utenti, ordini, eventi)
• Come le tabelle si relazionano (uno-a-molti, molti-a-molti)
• Cosa deve essere unico o obbligatorio (vincoli)
• Come rappresenti stati e storia (timestamp, campi di stato, record di audit)

Una buona progettazione dello schema fa sì che il modo naturale di porre domande sia anche il modo veloce.

Ottimizzazione delle query (in parole semplici)

L'ottimizzazione delle query consiste nel migliorare come recuperi o aggiorni i dati: riscrivere query, aggiungere indici, ridurre lavoro inutile e evitare pattern che provocano scansioni enormi.

Entrambi contano—ma l'ordine è importante

Questo articolo non vuol dire “schema buono, query cattive”. Parla dell'ordine delle operazioni: sistemare prima i fondamenti dello schema del database, poi ottimizzare le query che ne hanno davvero bisogno.

Imparerai perché le decisioni sullo schema dominano le prestazioni iniziali, come riconoscere quando lo schema è il vero collo di bottiglia e come farlo evolvere in sicurezza man mano che l'app cresce. È scritto per team prodotto, founder e sviluppatori che costruiscono app reali—non per specialisti di database.

Perché la progettazione dello schema guida la maggior parte delle prestazioni iniziali

Le prestazioni iniziali raramente dipendono da SQL geniale: dipendono da quanto dato il database è costretto a toccare.

La struttura determina quanto devi scandagliare

Una query può essere tanto selettiva quanto lo permette il modello dei dati. Se memorizzi “stato”, “tipo” o “proprietario” in campi poco strutturati (o sparsi in tabelle incoerenti), il database spesso deve scansionare molte più righe per trovare le corrispondenze.

Un buon schema restringe naturalmente lo spazio di ricerca: colonne chiare, tipi coerenti e tabelle ben definite permettono alle query di filtrare prima e leggere meno pagine da disco o memoria.

Mancanza di chiavi crea lavoro costoso

Quando mancano chiavi primarie e chiavi esterne (o non sono applicate), le relazioni diventano supposizioni. Questo sposta lavoro nello strato delle query:

• I JOIN diventano più grandi perché manca un percorso di join indicizzato e affidabile.
• I filtri diventano più complessi perché compensi duplicati, null e valori “quasi corrispondenti”.

Senza vincoli, si accumulano dati sporchi—e le query si rallentano all'aumentare delle righe.

Gli indici seguono lo schema (e non risolvono tutto)

Gli indici sono più utili quando combaciano con percorsi di accesso prevedibili: join su chiavi esterne, filtri su colonne ben definite, ordinamenti su campi comuni. Se lo schema mette attributi critici nella tabella sbagliata, mescola significati in una colonna o dipende dal parsing di testo, gli indici non ti salveranno—continuerai a scansionare e trasformare troppi dati.

Veloci per impostazione predefinita

Con relazioni pulite, identificatori stabili e confini di tabella sensati, molte query quotidiane diventano “veloci per impostazione predefinita” perché toccano meno dati e usano predicati semplici e favorevoli agli indici. L'ottimizzazione delle query diventa allora un passo finale, non un fuoco da estinguere continuamente.

La realtà nelle prime fasi: il cambiamento è costante

I prodotti in fase iniziale non hanno “requisiti stabili”—hanno esperimenti. Le feature vengono pubblicate, riscritte o cancellate. Un piccolo team gestisce roadmap, supporto e infrastruttura con poco tempo per rivedere decisioni passate.

Cosa cambia più spesso

Non è quasi mai il testo SQL a cambiare per primo. È il significato dei dati: nuovi stati, nuove relazioni, nuovi campi “oh dobbiamo anche tracciarlo…”, e workflow interi non immaginati al lancio. Questo churn è normale—ed è proprio per questo che le scelte di schema contano così tanto all'inizio.

Perché sistemare lo schema dopo è più difficile che sistemare una query

Riscrivere una query è di solito reversibile e locale: puoi spedire un miglioramento, misurarlo e fare rollback se serve.

Riscrivere uno schema è diverso. Una volta che hai dati reali dei clienti, ogni cambiamento strutturale diventa un progetto:

• Migrazioni che bloccano le tabelle o rallentano le scritture nelle ore di punta
• Backfill per popolare nuove colonne o ricostruire dati derivati
• Dual-write o tabelle shadow per mantenere l'app attiva durante la transizione
• Rischio di downtime se il cambiamento non è eseguibile online

Anche con buoni strumenti, le modifiche dello schema introducono costi di coordinamento: aggiornamenti del codice app, sequenza di deploy e validazione dei dati.

Come le scelte iniziali si sommano

Quando il database è piccolo, uno schema malconcio può sembrare “ok”. Con milioni di righe, lo stesso design provoca scansioni più ampie, indici più pesanti e join più costosi—e ogni nuova feature si costruisce su quella base.

Quindi l'obiettivo iniziale non è la perfezione. È scegliere uno schema che possa assorbire il cambiamento senza imporre migrazioni rischiose ogni volta che il prodotto impara qualcosa di nuovo.

Fondamentali di progettazione che prevengono query lente

La maggior parte dei problemi di “query lenta” all'inizio non riguarda trucchi SQL ma ambiguità nel modello dati. Se lo schema rende poco chiaro cosa rappresenta una riga o come le righe si relazionano, ogni query diventa più costosa da scrivere, eseguire e mantenere.

Parti da un piccolo insieme di entità core

Inizia nominando le poche cose senza cui il tuo prodotto non può funzionare: utenti, account, ordini, abbonamenti, eventi, fatture—ciò che è davvero centrale. Poi definisci le relazioni in modo esplicito: uno-a-molti, molti-a-molti (di solito con una tabella di join) e proprietà (chi “contiene” cosa).

Un controllo pratico: per ogni tabella dovresti poter completare la frase “Una riga in questa tabella rappresenta ___.” Se non ci riesci, la tabella probabilmente mescola concetti, costringendo poi a filtri e join complessi.

Rendi nomi e proprietà noiosamente coerenti

La coerenza evita join accidentali e comportamenti API confusi. Scegli convenzioni (snake_case vs camelCase, *_id, created_at/updated_at) e mantienile.

Decidi anche a chi appartiene un campo. Per esempio, “billing_address” appartiene a un ordine (istantanea al momento) o a un utente (predefinito corrente)? Entrambe le scelte possono essere valide—ma mescolarle senza chiarezza crea query lente e soggette a errori per “capire la verità”.

Scegli tipi di dato che rispecchiano la realtà

Usa tipi che evitano conversioni a runtime:

• Usa timestamp con regole di fuso orario comprese.
• Usa decimal per soldi (non float).
• Usa enum o tabelle di riferimento per categorie note.

Quando i tipi sono sbagliati, i database non possono confrontare in modo efficiente, gli indici diventano meno utili e le query spesso richiedono casting.

Non duplicare fatti senza un piano

Memorizzare lo stesso fatto in più punti (per esempio order_total e la somma di line_items) crea deriva. Se memorizzi un valore derivato, documentalo, definisci la sorgente della verità e assicurati che gli aggiornamenti siano coerenti (spesso tramite logica applicativa più vincoli).

Chiavi e vincoli: la velocità parte dall'integrità dei dati

Un database veloce è di solito un database prevedibile. Chiavi e vincoli rendono i dati prevedibili impedendo stati “impossibili”: relazioni mancanti, identità duplicate o valori che non significano ciò che l'app pensa. Questa pulizia incide direttamente sulle prestazioni perché il planner può fare assunzioni migliori.

Chiavi primarie: ogni tabella ha bisogno di un identificatore stabile

Ogni tabella dovrebbe avere una chiave primaria (PK): una colonna (o piccolo insieme di colonne) che identifica univocamente una riga e non cambia mai. Non è solo teoria: permette join efficienti, caching sicuro e riferimenti ai record senza ambiguità.

Una PK stabile evita anche workaround costosi. Se una tabella non ha un vero identificatore, l'app inizia a “identificare” righe tramite email, nome, timestamp o un insieme di colonne—portando a indici più ampi, join lenti e casi limite quando quei valori cambiano.

Chiavi esterne: integrità che aiuta l'ottimizzatore

Le foreign key (FK) impongono relazioni: un orders.user_id deve puntare a un users.id esistente. Senza FK, si infilano riferimenti invalidi (ordini per utenti cancellati, commenti per post mancanti), e ogni query deve filtrare difensivamente, usare left-join e gestire null.

Con le FK, il planner può ottimizzare i join con più sicurezza perché la relazione è esplicita e garantita. In più accumulerai meno righe orfane che gonfiano tabelle e indici.

I vincoli come guardrail per dati puliti e veloci

I vincoli non sono burocrazia, sono guardrail:

• UNIQUE evita duplicati che costringono l'app a lookup e pulizie extra. Esempio: un unico users.email canonico.
• NOT NULL evita logiche a tri-stato e rami imprevisti nelle query.
• CHECK mantiene i valori all'interno di un insieme noto (es. status IN ('pending','paid','canceled')).

Dati più puliti significano query più semplici, meno condizioni di fallback e meno join “giusto per sicurezza”.

Anti-pattern comuni che ti rallentano

• Nessuna foreign key: pagherai in seguito con job di pulizia e logica query complicata.
• Duplicazione del campo “email” (es. users.email e customers.email): identità conflittuali e indici duplicati.
• Stringhe di stato free-form: errori di battitura come "Cancelled" vs "canceled" creano segmenti nascosti che rompono filtri e report.

Se vuoi velocità all'inizio, rendi difficile memorizzare dati sbagliati. Il database ti ricompenserà con piani più semplici, indici più piccoli e meno sorprese di performance.

Normalizzazione vs denormalizzazione: un equilibrio pratico

Normalizzare significa memorizzare ogni “fatto” in un solo posto per evitare duplicazioni. Quando lo stesso valore è copiato in molte tabelle, gli aggiornamenti diventano rischiosi—una copia cambia e l'altra no, e l'app mostra risposte contrastanti.

Normalizzazione (default): un fatto, una casa

In pratica, normalizzare significa separare le entità in modo che gli aggiornamenti siano puliti e prevedibili. Per esempio, nome e prezzo di un prodotto stanno in products, non ripetuti dentro ogni riga d'ordine. Un nome di categoria sta in categories, referenziato tramite ID.

Questo riduce:

• dati duplicati (meno spazio, meno incoerenze)
• errori di aggiornamento (cambi una volta, si riflette ovunque)
• bug “qual è il valore corretto?”

Quando la sovra-normalizzazione danneggia

Normalizzare oltre misura porta a tante tabelle piccole che devono essere joinate continuamente per schermate comuni. Il database può restituire risultati corretti, ma le letture ordinarie diventano più lente e complesse perché ogni richiesta richiede molti join.

Un sintomo tipico: una pagina “semplice” (storico ordini) richiede 6–10 join e le prestazioni variano con traffico e cache.

Approccio pratico: normalizza i fatti core, denormalizza le letture più calde

Un bilanciamento sensato:

1. Normalizza i fatti core e la proprietà (fonte di verità). Mantieni attributi prodotto in products, nomi di categoria in categories e relazioni tramite FK.
2. Denormalizza con attenzione per le letture più frequentate—ma solo quando puoi spiegare il beneficio e come mantenerla corretta.

Denormalizzare significa duplicare intenzionalmente un piccolo pezzo di dato per rendere una query frequente più economica (meno join, liste più veloci). La parola chiave è attenzione: ogni campo duplicato necessita di un piano per rimanere aggiornato.

Esempio: prodotti, categorie e elementi d'ordine

Una configurazione normalizzata potrebbe essere:

• products(id, name, price, category_id)
• categories(id, name)
• orders(id, customer_id, created_at)
• order_items(id, order_id, product_id, quantity, unit_price_at_purchase)

Nota la sottile vittoria: order_items memorizza unit_price_at_purchase (una forma di denormalizzazione) perché serve l'accuratezza storica anche se il prezzo del prodotto cambia dopo. Questa duplicazione è intenzionale e stabile.

Se la schermata più comune è “ordini con riepilogo degli articoli”, potresti anche denormalizzare product_name in order_items per evitare il join su products per ogni lista—ma solo se sei pronto a mantenerlo sincronizzato (o ad accettare che sia un'istantanea al momento dell'acquisto).

La strategia degli indici segue lo schema, non il contrario

Gli indici sono spesso trattati come un pulsante magico per la velocità, ma funzionano bene solo quando la struttura della tabella ha senso. Se continui a rinominare colonne, dividere tabelle o cambiare relazioni, il set di indici sarà in continuo cambiamento. Gli indici funzionano meglio quando le colonne e i modi in cui l'app filtra/ordina sono abbastanza stabili da non richiedere ricostruzioni settimanali.

Parti dalle domande che l'app fa di più

Non serve prevedere tutto, ma serve una lista corta delle query che contano davvero:

• “Trova un utente per email.”
• “Mostra ordini recenti per un cliente.”
• “Elenca fatture per stato, più recenti prima.”

Queste frasi si traducono direttamente in quali colonne meritano un indice. Se non riesci a dirle ad alta voce, di solito è un problema di chiarezza dello schema—non di indicizzazione.

Indici compositi, spiegati semplicemente

Un indice composito copre più di una colonna. L'ordine delle colonne conta perché il database può usare l'indice da sinistra a destra.

Per esempio, se filtri spesso per customer_id e poi ordini per created_at, un indice su (customer_id, created_at) è tipicamente utile. L'inverso (created_at, customer_id) potrebbe non aiutare la stessa query.

Non indicizzare tutto

Ogni indice ha un costo:

• Scritture più lente: insert/update devono aggiornare anche l'indice.
• Più spazio: gli indici possono occupare una grande parte del database.
• Più complessità: indici extra rendono manutenzione e tuning più difficili.

Uno schema pulito restringe gli indici “giusti” a un piccolo insieme che corrisponde ai reali pattern di accesso—senza pagare continuamente il peso su scritture e spazio.

Prestazioni di scrittura: il costo nascosto di uno schema disordinato

Le app lente non sono sempre rallentate dalle letture. Molti problemi di performance iniziali emergono durante insert e update—signup, checkout, job in background—perché uno schema disordinato fa fare lavoro extra a ogni scrittura.

Perché le scritture diventano costose

Alcune scelte di schema moltiplicano silenziosamente il costo di ogni modifica:

• Righe larghe: mettere decine (o centinaia) di colonne in una tabella significa righe più grandi, più I/O e più churn nella cache—anche se la maggior parte delle colonne è raramente usata.
• Troppi indici: gli indici velocizzano le letture, ma ogni insert/update deve aggiornare ciascun indice.
• Trigger e cascade: i trigger possono nascondere lavoro (insert/update aggiuntivi) dietro a un semplice INSERT. Le foreign key con cascade sono corrette e utili, ma aggiungono lavoro al tempo di scrittura che cresce con i dati correlati.

Read-heavy vs write-heavy: scegli dove far male intenzionalmente

Se il carico è read-heavy (feed, pagine di ricerca), puoi permetterti più indici e qualche denormalizzazione. Se è write-heavy (ingestione eventi, telemetry, ordini ad alto volume), dai priorità a uno schema che mantenga le scritture semplici e prevedibili, poi aggiungi ottimizzazioni per le letture dove serve.

Pattern comuni delle prime fasi che danneggiano le scritture

• Audit log: utili per compliance, ma evita di salvare snapshot enormi a ogni update.
• Tabelle di eventi: append-only scalano bene, ma possono gonfiarsi se memorizzi payload ridondanti.
• Soft delete: comode, ma aumentano la dimensione degli indici e possono rallentare update/query se non pianificate.

Mantieni scritture semplici preservando la storia

Un approccio pratico:

• Conserva lo “stato corrente” in una tabella e la storia in una tabella append-only separata.
• Mantieni le righe di storia narrow (solo chi/quando/cosa è cambiato).
• Aggiungi indici alla storia basati su pattern di accesso reali (di solito entity_id, created_at).
• Evita i trigger per l'auditing all'inizio; preferisci scritture esplicite dall'app così il costo è visibile e testabile.

Percorsi di scrittura puliti ti danno margine di manovra—e rendono l'ottimizzazione delle query molto più semplice in seguito.

Come ORMs e API amplificano le decisioni di schema

Gli ORM rendono il lavoro col database più semplice: definisci modelli, chiami metodi e i dati compaiono. Il problema è che un ORM può anche nascondere SQL costose fino a quando non iniziano a pesare.

ORM: comodità che può mascherare pattern lenti

Due trappole comuni:

• Join inefficienti: un .include() o un serializer nidificato può trasformarsi in join ampi, righe duplicate o ordinamenti pesanti—soprattutto se le relazioni non sono chiaramente definite.
• N+1 queries: prendi 50 record e l'ORM silenziosamente esegue altre 50 query per caricare i dati correlati. Funziona in sviluppo e collassa sotto traffico reale.

Uno schema ben progettato riduce la probabilità che questi pattern emergano e li rende più facili da rilevare quando succedono.

Relazioni chiare rendono l'uso dell'ORM più sicuro

Quando le tabelle hanno foreign key esplicite, vincoli di unicità e NOT NULL, l'ORM può generare query più sicure e il codice può contare su assunzioni coerenti.

Per esempio, imporre che orders.user_id esista (FK) e che users.email sia unico evita intere classi di edge case che altrimenti diventerebbero controlli a livello applicativo e lavoro di query aggiuntivo.

Le API trasformano le scelte di schema nel comportamento del prodotto

Il design delle API è a valle dello schema:

• ID stabili (e tipi coerenti) semplificano URL, caching e stato client.
• La paginazione funziona meglio quando puoi ordinare per una colonna indicizzata e monotona (spesso created_at + id).
• Il filtraggio diventa prevedibile quando le colonne rappresentano attributi reali (non stringhe sovraccaricate o blob JSON) e i vincoli mantengono i valori puliti.

Fallo diventare un workflow, non una missione di salvataggio

Tratta le decisioni di schema come ingegneria di prima classe:

• Usa migrazioni per ogni cambiamento, riviste come codice (review delle migrazioni).
• Aggiungi leggere “revisioni dello schema” per nuovi endpoint: quali tabelle, quali chiavi, quali vincoli, quale forma avranno le query.
• In staging, registra le query generate dall'ORM e segnala pattern N+1 prima della produzione.

Se costruisci velocemente con uno workflow chat-driven (ad esempio generando un'app React più un backend Go/PostgreSQL con Koder.ai), aiuta rendere la “revisione dello schema” parte della conversazione fin da subito. Puoi iterare rapidamente, ma vuoi comunque vincoli, chiavi e un piano di migrazione decisi—soprattutto prima che arrivi il traffico.

Segnali d'allarme precoce che lo schema è il collo di bottiglia

Alcuni problemi di performance non sono “SQL cattiva” ma il database che lotta contro la forma dei tuoi dati. Se vedi gli stessi problemi attraverso molti endpoint e report, spesso è un segnale di schema, non un'opportunità di tuning della query.

Sintomi comuni da tenere d'occhio

Filtri lenti sono un classico. Se condizioni semplici come “trova ordini per cliente” o “filtra per data di creazione” sono costantemente lente, il problema può essere chiavi mancanti, tipi non corrispondenti o colonne che non sono indicizzabili efficacemente.

Un altro campanello è il numero di join che esplode: una query che dovrebbe unire 2–3 tabelle finisce per concatenarne 6–10 per rispondere a una domanda base (spesso per via di lookup eccessivi, pattern polimorfici o design “tutto in una tabella”).

Controlla anche valori incoerenti in colonne usate come enum—soprattutto campi di stato (“active”, “ACTIVE”, “enabled”, “on”). L'incoerenza costringe query difensive (LOWER(), COALESCE(), catene di OR) che restano lente nonostante il tuning.

Lista di controllo rapida dello schema (veloce da verificare)

• Indici mancanti sulle foreign key (i join diventano scansioni complete con la crescita delle tabelle).
• Tipi di dato sbagliati (es. ID memorizzati come stringhe, date come testo, soldi come float).
• Tabelle EAV (Entity–Attribute–Value) usate per dati core: flessibili all'inizio, ma filtri/ordinamenti diventano molti join e predicati difficili da indicizzare.

Diagnostica semplice e indipendente dagli strumenti

Inizia con controlli reali: conteggi di righe per tabella e cardinalità per colonne chiave (quanti valori distinti). Se una colonna “status” dovrebbe avere 4 valori ma ne trovi 40, lo schema sta già perdendo complessità.

Poi guarda i piani di query per gli endpoint lenti. Se vedi scansioni sequenziali ripetute su colonne di join o grandi set di risultati intermedi, schema e indicizzazione sono probabilmente la radice.

Infine, abilita e rivedi i log delle query lente. Quando molte query diverse sono lente allo stesso modo (stesse tabelle, stessi predicati), è di solito un problema strutturale da correggere a livello di modello.

Far evolvere lo schema in sicurezza man mano che cresci

Le scelte iniziali raramente sopravvivono al contatto con utenti reali. L'obiettivo non è “azzeccare tutto” ma cambiarlo senza rompere la produzione, perdere dati o bloccare il team per giorni.

Un processo leggero e ripetibile per i cambiamenti

Un workflow pratico che scala da un'app di una persona a team più grandi:

1. Modella: descrivi la nuova forma (tabelle/colonne, relazioni e cosa diventa fonte di verità). Includi record d'esempio ed edge case.
2. Migra: aggiungi nuove strutture in modo backward-compatible (prime colonne/tabelle nuove; evita di rimuovere o rinominare subito).
3. Backfill: popola i nuovi campi dai dati esistenti a batch. Traccia il progresso per poter riprendere.
4. Valida: aggiungi vincoli solo dopo che i dati sono puliti (es. NOT NULL, foreign key). Esegui controlli che confrontino output vecchio vs nuovo.

Feature flag e dual writes (usali con parsimonia)

La maggior parte dei cambiamenti di schema non richiede rollout complessi. Preferisci la strategia “espandi e contrai”: scrivi codice che possa leggere sia il vecchio sia il nuovo formato, poi passa le scritture quando sei sicuro.

Usa feature flag o dual writes solo quando serve un cutover graduale (alto traffico, backfill lungo o più servizi coinvolti). Se fai dual write, aggiungi monitoraggio per rilevare deriva e definisci quale lato vince in caso di conflitto.

Rollback e test delle migrazioni che riflettano la realtà

I rollback sicuri partono da migrazioni reversibili. Prova la strada del “tornare indietro”: eliminare una colonna nuova è facile; recuperare dati sovrascritti no.

Testa migrazioni su volumi realistici. Una migrazione che impiega 2 secondi su un portatile può bloccare tabelle per minuti in produzione. Usa conteggi di righe e indici simili alla produzione e misura i tempi.

Qui gli strumenti di piattaforma riducono il rischio: deployment affidabili più snapshot/rollback e la possibilità di esportare codice rendono più sicuro iterare su schema e logica app insieme. Se usi Koder.ai, sfrutta snapshot e la modalità di pianificazione quando stai per introdurre migrazioni che richiedono attenzione.

Documenta le decisioni per chi verrà dopo (incluso il futuro te)

Tieni un breve diario dello schema: cosa è cambiato, perché e quali compromessi sono stati accettati. Collegalo a /docs o al README del repo. Includi note tipo “questa colonna è intenzionalmente denormalizzata” o “foreign key aggiunta dopo backfill il 2025-01-10” così chi modifica in futuro non ripeta errori passati.

Quando ottimizzare le query (e un ordine sensato delle operazioni)

L'ottimizzazione delle query conta—ma rende di più quando lo schema non ti ostacola. Se le tabelle mancano di chiavi chiare, le relazioni sono incoerenti o la regola “una riga per una cosa” è violata, puoi passare ore a ottimizzare query che verranno riscritte la settimana dopo.

Un ordine pratico di priorità

1. Risolvi prima i blocchi dello schema. Parti da tutto ciò che rende difficile interrogare correttamente: chiavi primarie mancanti, foreign key incoerenti, colonne che mescolano più significati, fonti di verità duplicate o tipi non corretti (es. date come stringhe).

2. Stabilizza i pattern di accesso. Una volta che il modello dati rispecchia come si comporta l'app (e probabilmente per i prossimi sprint), il tuning delle query diventa durevole.

3. Ottimizza le query principali—non tutte. Usa log/APM per identificare le query più lente e frequenti. Un endpoint che riceve 10.000 richieste al giorno solitamente vale più di un report amministrativo raro.

L'80/20 dell'ottimizzazione precoce

I maggiori miglioramenti iniziali vengono da pochi interventi:

• Aggiungi l'indice giusto per i filtri e i join più comuni (e verifica che venga effettivamente usato).
• Restituisci meno colonne (evita SELECT *, specialmente su tabelle wide).
• Evita join inutili—a volte un join esiste solo perché lo schema ti costringe a “scoprire” attributi di base.

Impostare le aspettative: è un lavoro continuo, ma le basi vengono prima

Il lavoro sulle performance non finisce mai, ma l'obiettivo è renderlo prevedibile. Con uno schema pulito ogni nuova feature aggiunge carico incrementale; con uno schema disordinato ogni feature aggiunge confusione composita.

Checklist per questa settimana

• Elenca le 5 query più lente e le 5 più frequenti.
• Per ciascuna, conferma: chiave primaria presente, join sono chiave-a-chiave, e i tipi sono corretti.
• Aggiungi un indice che corrisponda al filtro/ordine dominante.
• Sostituisci SELECT * in un percorso caldo.
• Misura di nuovo e tieni una nota semplice “prima/dopo” per il prossimo sprint.