Che cos'è un indice del database?

Un indice del database è una struttura di ricerca ordinata che permette al motore di trovare le righe corrispondenti senza scansionare l’intera tabella. L’analogia del libro è esatta: nessuno trova “idempotenza” in un volume di 900 pagine leggendolo – si consulta l’indice e si salta alla pagina. I database fanno la stessa scelta a ogni query, e il fatto che possano saltare o no è la differenza più comune tra una query da 5 millisecondi e una da 5 secondi.

Punti chiave

L’indice, creato e percepito

-- Il cavallo da tiro: un indice composito sagomato sulla query calda
CREATE INDEX orders_pending ON orders (status, created_at);

-- Specializzazioni della stessa idea:
CREATE UNIQUE INDEX users_email ON users (email);         -- vincolo + velocità
CREATE INDEX unshipped ON orders (created_at)
  WHERE shipped = false;                                  -- parziale: solo il sottoinsieme caldo

-- Il prima/dopo, visto dal piano:
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at > now() - interval '1 day';
--  prima:   Seq Scan on orders   (righe esaminate: 4.812.309)
--  dopo:    Index Scan using orders_pending   (righe esaminate: 1.214)

Il codice applicativo incontra la stessa fisica attraverso la forma della query – questa query è la specifica dell’indice (status, createdAt), qualunque sia la superficie che la scrive:

// JavaScript / Node.js — Back4app JS SDK
// The query shape tells you the index: (status, createdAt)
const query = new Parse.Query('Order');
query.equalTo('status', 'pending');       // equality first…
query.greaterThan('createdAt', since);    // …then the range
query.descending('createdAt');            // …sorted by the same column
const backlog = await query.find();
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// Flutter / Dart — Back4app Flutter SDK
// The query shape tells you the index: (status, createdAt)
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'pending')      // equality first…
  ..whereGreaterThan('createdAt', since)   // …then the range
  ..orderByDescending('createdAt');        // …sorted by the same column
final response = await query.query();
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// iOS / Swift — Back4app Swift SDK
// The query shape tells you the index: (status, createdAt)
let query = Order.query("status" == "pending", "createdAt" > since)
  .order([.descending("createdAt")])
query.find { result in
  if case .success(let backlog) = result { render(backlog) }
}
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

// Android / Kotlin — Back4app Android SDK
// The query shape tells you the index: (status, createdAt)
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "pending")     // equality first…
query.whereGreaterThan("createdAt", since)  // …then the range
query.orderByDescending("createdAt")        // …sorted by the same column
query.findInBackground { backlog, e -> if (e == null) render(backlog) }
// Indexed: milliseconds at any size. Unindexed: a full collection scan.

Come funziona il salto

La struttura predefinita, in ogni motore, è il B-tree: poco profondo, ordinato, auto-bilanciato – tre o quattro livelli coprono centinaia di milioni di voci, e le sue foglie sono concatenate, ed è per questo che una sola struttura serve allo stesso modo uguaglianza, intervalli e ORDER BY. È questa versatilità a rendere “nel dubbio, B-tree” il consiglio permanente, con le alternative nel ruolo di specialiste.

B-tree vs. hash vs. gli specialisti

Quale tipo di indice conviene usare?

Due regole reggono la riga del composito: la regola del prefisso sinistro – un indice su (a, b, c) serve a, (a, b), (a, b, c), mai b da solo – e prima l’uguaglianza, intervallo e ordinamento per ultimi nell’ordine delle colonne (il mnemonico ESR dell’indicizzazione nei database documentali, dove gli stessi B-tree fanno lo stesso lavoro).

Quando indicizzare – e quando no

Indicizzare: le colonne nei filtri WHERE frequenti; le chiavi di join e i campi puntatore (alcuni motori non indicizzano mai le chiavi esterne in automatico – un classico della scansione silenziosa); le colonne ORDER BY sui percorsi caldi; e sempre con la selettività in mente – una colonna email (milioni di valori distinti) si guadagna il posto, un flag di stato (tre valori) di norma no da solo, anche se brilla in testa a un composito con un intervallo dietro. Non indicizzare: le tabelle piccole che il motore scansiona più in fretta di quanto cerchi; le tabelle calde in scrittura oltre i pochi indici essenziali; le colonne già servite dal prefisso sinistro di un indice esistente; e tutto ciò per cui non si sa nominare una query – un indice senza query è pura tassa sulle scritture. Il ciclo di verifica: passare EXPLAIN sulle query lente in cerca di scansioni, controllare le statistiche di utilizzo per trovare gli indici morti, aggiungere ed eliminare di conseguenza.

Casi d’uso tipici

• La query della lista calda. Filtri su stato più data dietro ogni dashboard e ogni feed – il terreno di casa dell’indice composito.
• Campi di accesso e di ricerca. Email, username, ID esterni – indici univoci che fanno vincolo e velocità in una mossa.
• Percorsi di join e di puntatore. Ogni chiave esterna e ogni puntatore che le query attraversano; il complice silenzioso del problema N+1 è uno di questi non indicizzato.
• Filtri multi-tenant. Compositi che iniziano dal tenant – la regola dell’architettura multi-tenant per cui ogni indice parte da tenant_id.
• Ricerca e geo. Indici invertiti e spaziali che alimentano le query fuori portata dei B-tree.

Conviene aggiungere quell’indice? Matrice decisionale

La disciplina in una frase: gli indici si creano in risposta alle query, si rivedono rispetto all’uso effettivo e si eliminano senza sentimentalismi.

Limiti e trade-off

• Le scritture pagano le letture. Ogni indice è un’altra struttura che ogni scrittura deve mantenere – i caricamenti in massa, com’è noto, vanno più veloci con gli indici eliminati prima e ricostruiti dopo.
• L’archiviazione è reale. Gli indici rivaleggiano spesso con la dimensione della tabella stessa; quelli di copertura in particolare barattano disco per velocità.
• Decide l’ottimizzatore, non chi scrive la query. Un indice poco selettivo può essere ignorato a ragione; statistiche stantie possono far ignorare a torto un indice buono – il piano è la verità.
• Gli errori di ordine neutralizzano i compositi. (created_at, status) e (status, created_at) sono strumenti diversi; la regola del prefisso sinistro non perdona nulla.
• Gli indici non aggiustano la query. Wildcard iniziali, funzioni applicate alle colonne e cicli N+1 sconfiggono l’indicizzazione dall’alto – la forma della query viene prima.

Indici su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La gestione degli indici vive accanto allo schema nella dashboard: si creano, si rivedono e si eliminano indici per classe – a campo singolo o composti – sull’archivio basato su MongoDB che le query dell’SDK interrogano davvero, seguendo la stessa logica dei B-tree e dell’ESR vista sopra. La query nelle schede di codice e l’indice che la serve si progettano nello stesso posto, che è esattamente dove vuole stare la disciplina di indicizzare ciò che si interroga.