Newsgroup: it.comp.software.database
Titolo: Velocizzare i database

Ciao a tutti,
scusate la domanda che potra' sembrarvi banale, :)
Quali sono i metodi (o i trucchi, se ce ne sono) per velocizzare un
database (relazionale)? Ovvero, quale ipotetica classifica fareste?
-Indicizzazione (e se si quanti campi? uno? E quali ...)
-Niente query con la select * ma sempre con target list
-parametro "limit"
-query semplici
Eventuali e varie:
  -record piccoli (pochi campi)?
  -relazioni piccole (sopra n record archiviare e cambiare, es. n =
50.000 record)
  -altro?
Grazie!
ciao,
Leonardo  

Bewel il Thursday 08 November 2001 22:03 scrisse:

Su Mysql, ma penso che sia una regola generale, indicizzare e' normalmente 
la soluzione finale per le performace. 
-- 
frank@office
DebianSid-2.4.13 on a P|||@1GHz-256MB 

 database (relazionale)? Ovvero, quale ipotetica classifica fareste?
Dipende fortemente dal database che si utilizza. Sapendo quale
processo viene seguito dal parser/ottimizzatore e' possibile
dare qualche dritta.
Vedi articolo sull'ottimizzazione delle query su
www.soft-land.org
Davide

Scusate l'introduzione, ma volevo avere un chiarimento dato che parlevate
di indici. Un mio collega tempo fa mi disse che gli Indici rallentano le
ricerche
o rallentano gli inserimenti e modifiche.
Grazie
Tiziano

 ricerche o rallentano gli inserimenti e modifiche.
Se devi mantenere un'indice oltre alla tabella, un'inserimento e/o
una modifica viene rallentato (ovviamente), infatti il trucco sta' nel
non fare indici alla dai' che la va', ma farli solamente dove
effettivamente servono. Se la struttura delle tue query e' tale per
cui il db fa' sempre un tablescan, un'indice non migliora di certo le
tue prestazioni, semmai le peggiora. Pero' se sei in grado di
forzare l'ottimizzatore ed usare l'indice, la query sara' piu' veloce.
Davide

"Tiziano"

Ogni database è accompagnato da documentazioni molto analitiche su come e
cosa indicizzare per migliorare le prestazioni di selezione senza
appesantire inutilmente il DB.
Per ottenere il massimo serve esperienza (e qualche test prestazionale)...
Ciao, warp


www.soft-land.org
Lo conoscevo (grazie, comunque). Tuttavia, li' parla espressamente di
ottimizzazione per Sql Server di Microsoft, che non utilizzo.
Tuttavia, lo rileggero'. Adesso sto cercando se sul sito di postgres
c'e' qualcosa di specifico per la loro versione.
Grazie.
Leonardo



Innanzitutto chiariamo il discorso sugli indici:
	servono a velocizzare le ricerche, quindi le select, ma di
conseguenza rallentano le operazioni di insert e modifica.
	inoltre, l'engine non è detto che utilizzi sempre e per forza
l'indice, solitamente se la lettura dell'indice richiede un maggiore
I/O rispetto ad un table scan, è molto probabile che l'indce nn venga
utilizzato.
	detto questo bisogna analizzare la struttura della base dati e
se esistono campi sui quali sono frequenti le where ad esempio 'SELECT
A,B FROM C WHERE D = X allora quello è un buon candidato per un
indice.
Un altro consiglio e di richiedere solo i campi che effettivamente
servono, evitare quindi 'SELECT * FROM A', anche le subquery sarebbe
meglio evitarle, meglio le join rispetto alle 'WHERE IN (SELECT ...)'.
Se il db che utilizzi le supporta, sicuramente introdurre l'uso delle
STORED PROCEDURE'
poi t metti li e fai ore ed ore di test per vedere se e come le tue
modificano impattano le prestazioni, l'esperienza è sempre il migliore
esperto.
ciao
ilbric