Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →
Utilizzo degli indici
Gli indici sono strutture dati che consentono al database di individuare righe senza scansionare l'intera tabella. Senza indice, una query deve esaminare ogni riga per trovare corrispondenze. Con un indice, il database può saltare direttamente alle righe rilevanti — riducendo drasticamente il numero di righe esaminate.
Gli indici accelerano le operazioni di lettura ma aggiungono overhead alle scritture (inserimenti, aggiornamenti, eliminazioni) poiché l'indice deve rimanere sincronizzato, quindi vanno creati con cautela e solo quando necessari.
Sono buoni candidati per gli indici le colonne usate frequentemente in clausole WHERE, join e ordinamenti. Quando si utilizzano più colonne come filtro, può essere utile creare un indice composito, ma considera che l'ordine delle colonne è importante — posiziona per prime quelle più selettive (con valori più univoci).
Analisi delle prestazioni delle query
La maggior parte dei database consente di ispezionare l'esecuzione di una query attraverso un piano di esecuzione. Comprendere questo piano aiuta a identificare indici mancanti e ottimizzare la costruzione delle query confrontando diverse modalità di recupero degli stessi dati.
CockroachDB
Use EXPLAIN ANALYZE (same syntax as PostgreSQL):
EXPLAIN ANALYZE SELECT * FROM "user" WHERE "firstName" = 'Timber';
Look for full scan (no index) vs scan with a specific index name.
Google Spanner
Use the Query Plan visualizer in the Google Cloud Console, or run a query in PLAN/PROFILE mode via the gcloud CLI:
gcloud spanner databases execute-sql DATABASE_ID \
--instance=INSTANCE_ID \
--query-mode=PROFILE \
--sql="SELECT * FROM user WHERE firstName = 'Timber'"
Look for Table Scan (no index) vs Index Scan in the returned plan.
MariaDB
Use EXPLAIN or ANALYZE to inspect the query execution plan:
ANALYZE SELECT * FROM user WHERE firstName = 'Timber';
Check the type column — ALL means a full table scan, while ref, range, or index indicate index usage. The key column shows which index was chosen.
MongoDB
Use the explain() method on a query to see the execution plan:
db.user.find({ firstName: "Timber" }).explain("executionStats")
Look for COLLSCAN (collection scan — no index) vs IXSCAN (index scan).
MS SQL Server
Use the execution plan to analyze queries. In SQL Server Management Studio, press Ctrl+M to include the actual execution plan, then run your query. Programmatically:
SET STATISTICS IO ON;
SELECT * FROM [user] WHERE firstName = 'Timber';
SET STATISTICS IO OFF;
Look for Table Scan (no index) vs Index Seek or Index Scan in the execution plan.
MySQL
Use EXPLAIN to inspect the query execution plan:
EXPLAIN SELECT * FROM user WHERE firstName = 'Timber';
Check the type column — ALL means a full table scan, while ref, range, or index indicate index usage. The key column shows which index was chosen.
This also applies to Amazon Aurora MySQL, which uses the same query engine and EXPLAIN syntax. See Aurora MySQL tuning for Aurora-specific guidance.
Oracle
Use EXPLAIN PLAN to inspect the execution plan:
EXPLAIN PLAN FOR SELECT * FROM "user" WHERE "firstName" = 'Timber';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
Look for TABLE ACCESS FULL (no index) vs INDEX RANGE SCAN or INDEX UNIQUE SCAN.
PostgreSQL
Use EXPLAIN ANALYZE to see how PostgreSQL executes a query and whether it uses indexes:
EXPLAIN ANALYZE SELECT * FROM "user" WHERE "firstName" = 'Timber';
Look for Seq Scan (full table scan — no index used) vs Index Scan or Index Only Scan (index used).
This also applies to Amazon Aurora PostgreSQL, which uses the same query engine and EXPLAIN syntax. Aurora also offers query plan management for capturing and controlling execution plans.
SAP HANA
Use EXPLAIN PLAN FOR to inspect the execution plan:
EXPLAIN PLAN FOR SELECT * FROM "user" WHERE "firstName" = 'Timber';
SELECT * FROM EXPLAIN_PLAN_TABLE;
Look for TABLE SCAN (no index) vs INDEX SCAN or INDEX SEEK in the operator column.
SQLite
Use EXPLAIN QUERY PLAN to see how SQLite resolves a query:
EXPLAIN QUERY PLAN SELECT * FROM user WHERE firstName = 'Timber';
Look for SCAN (no index) vs SEARCH (index used) in the output.
Definizione degli indici in TypeORM
TypeORM supporta la creazione di indici sulle colonne delle tabelle tramite il decoratore @Index.
- Basic index
- Composite index
- Join column
import { Entity, PrimaryGeneratedColumn, Column, Index } from "typeorm"
@Entity()
export class User {
@PrimaryGeneratedColumn()
id: number
@Column()
@Index()
email: string
@Column()
firstName: string
}
import { Entity, PrimaryGeneratedColumn, Column, Index } from "typeorm"
@Entity()
@Index(["lastName", "firstName"]) // most selective column first
export class User {
@PrimaryGeneratedColumn()
id: number
@Column()
firstName: string
@Column()
lastName: string
}
import {
Entity,
PrimaryGeneratedColumn,
Column,
ManyToOne,
Index,
} from "typeorm"
import { User } from "./User"
@Entity()
export class Post {
@PrimaryGeneratedColumn()
id: number
@Column()
title: string
@ManyToOne(() => User)
@Index() // index foreign key columns to speed up joins
author: User
}
Per una panoramica completa sui diversi tipi di indice (univoco, spaziale, fulltext, concorrente e altri), consulta la guida Indici.
Un'indicizzazione corretta è spesso il miglioramento prestazionale più significativo applicabile — inizia analizzando le query più lente con gli strumenti per piani di esecuzione sopra descritti, poi aggiungi indici dove hanno maggiore impatto.