Newsgroup: it.comp.software.database
Titolo: indici: fenomenali!

Salve a tutti,
ho scoperto l'acqua calda....
cmq vorrei evidenziare il fatto che gli
indici incrementano in modo incredibile le
prestazioni di ricerca dul db..
La mia esperienza di stamattina:
db: mysql
query:
select stato,polcli.pol,polcli.decorr, totrata from polcli inner join titcli
on titcli.pol = polcli.pol where polcli.npc= '023554';
archivio polcli di circa 50.000 record
archivio titcli di circa 60.000 record
indici creati su
polcli.pol
polcli.npc
titcli.pol
tempo esecuzione senza indici = 17,49 sec
tempo esecuzione con indici = 0,02 sec!!!
bye
ringo

 prestazioni di ricerca dul db..
ROTFL è poco per rendere l'idea...
DOUBLEROTFL!
-- 
punkarruso

 prestazioni di ricerca dul db..
alleluya alleluya finalmente farai felice il tuo dba che fino ad oggi si
trovava il server con query lente che intasavano solo cpu.
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch

 ha scritto nel messaggio
news:pJfIa.101147$Ny5.2...@twister2.libero.it...

query:
select stato,polcli.pol,polcli.decorr, totrata from polcli inner join titcli
on titcli.pol = polcli.pol where polcli.npc= '023554';
tempo esecuzione senza indici = 17,49 sec
tempo esecuzione con indici = 0,02 sec!!!
nn si rende l'idea? :-)

 ha scritto nel messaggio
news:bcs1us$8c3$1...@rex.ip-plus.net...

meglio tardi che mai.....
:-)

 meglio tardi che mai.....
hai perfettamente ragione ti consiglio di dare un occhio al capitolo
optimizing sul sito di 
mysql.com
 per migliorare ulteriormente le
prestazioni.


 nn si rende l'idea? :-)
dai, non te la prendere... ma e' come se qualcuno ti dicesse: ho scoperto
che con la ferrari si va piu' veloce che in bicicleta !
:)
Paulus
--------------------------------
Inviato via 
http://usenet.libero.it

 wrote in message
news:bcs0ft$if0$1...@newsread.albacom.net...


 grazie
de nada


 trovava il server con query lente che intasavano solo cpu.
adesso invece trova il server con i dischi pieni! ;)
[scherzo]

 prestazioni di ricerca dul db..
Beato te, io ho una tabella su cui faccio 18 tipi di query differenti,
ma quella piu` lenta e pesante non mi e` possibile ottimizzarla (e` una
query secca, in quanto mi deve tirare fuori tutti i dati della tabella)
Henryx
P.S. stavo pensando, e se facessi una query del tipo `SELECT col1, col2,
col3 FROM tabella WHERE col1 = col1 AND col2 = col2 AND col3 = col3`?
-- 
GnuPG fingerprint = 42F9 521B 63C7 89FE 354C  89FA 4E49 3E2D 2EB6 B014


:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

 accedere alla tabella.
Veramente, come l'hai scritta te, essite un solo modo di accesso:
 FULL TABLE SCAN, visto che non esiste where condition.

:


Scusa, non vedo perche'. Se esiste un indice che contiene le copie dei
contenuti delle tre tabelle, ed e' aggiornato (com'e' di solito), quei
dati possono essere letti indifferentemente dalla tabella oppure dagli
indici.
Mi rendo conto che dipende da come sono organizzati i dati all'interno
degli indici, e quindi da quale database andiamo a esaminare. Per es.,
Sybase chiama questo trucco "leaf scan" o "index covering".
Il motore del DB valuta cosa gli conviene fare tenendo conto del costo
dell'accesso all'indice (strutture, ecc.), e del costo dell'accesso ai
dati crudi (tempo di trasferimento dal disco). E immagino che si debba
tener conto dell'ordinamento implicito del database... per esempio con
PostgreSQL mi sembra che la mancanza di un ORDER BY equivalga ad ORDER
BY oid, sicche' per usare gli indici dovrei chiedere
SELECT col1, col2, col3 FROM tabella ORDER BY col1, col2, col3;
(non e' necessario il WHERE).
Provandoci con una tabella a casaccio, in effetti il full scan impiega
41.93 msec, l'index scan 83.34 msec; questo, suppongo perche' utilizzo
un disco veloce. Appesantendo una tabella con dati su altre colonne ho
pero' un full table scan di 232.77 msec, mentre l'index scan rimane su
83.34 msec, e in _questo_ caso mi conviene.
Sicche' ritornando al discorso originale, se lo scopo del WHERE era di
forzare l'uso degli indici, e se l'engine non dispone di mezzi per far
usare gli indici "a forza" (PostgreSQL: "SET ENABLE_SEQSCAN=OFF;"), io
proverei a specificare una ORDER BY, con gli stessi campi elencati nel
file indice e nello stesso ordine.
Salvo errori ed omissioni :-)
