Aiuto con database e ottimizzazione query
Clicca QUI per vedere il messaggio nel forum |
| ripe |
Qui vi voglio, esperti di database! :D
Sto realizzando un'applicazione web con una tabella che contiene un campo di tipo nvarchar(MAX) (l'equivalente di ntext, un grosso testo in codifica UNICODE tanto per intenderci).
Ebbene, ho una query che legge dal DB tutti i record di questa tabella (circa 6000), e i risultati sono disarmanti: se inserisco nei campi della SELECT anche quello che contiene il testo, ci vogliono ben 23 secondi, se invece eseguo la selezione senza neanche un secondo!!! :shock:
Il problema è che nessun utente attenderà 23 secondi, per vedersi visualizzati i suoi 10 record richiesti! :asd:
C'è qualche soluzione fattibile? Avevo pensato di restituire i record senza il grosso campo di testo, per poi recuperarlo in un secondo momento con un'altra query quando richiesto. Ma non mi piace perchè mi sa molto di workaround...
Un'ultima richiesta: c'è differenza prestazionale nell'unire due tabelle tra questi due modi?
1) SELECT * FROM Tabella1, Tabella2 WHERE Tabella1.ID = Tabella2.ID
2) SELECT * FROM Tabella1 INNER JOIN Tabella 2 ON Tabella1.ID = Tabella2.ID
Grazie a chi vorrà darmi una mano! |
| yeah |
SELECT * FROM Tabella1 INNER JOIN Tabella 2 ON Tabella1.ID = Tabella2.ID
Mi è stato insegnato a fare i JOIN con la parola JOIN, non con una condizione in WHERE, quindi consiglio la (2) :D però non conosco le specifiche del linguaggio per poterlo affermare con certezza.
Ebbene, ho una query che legge dal DB tutti i record di questa tabella (circa 6000), e i risultati sono disarmanti: se inserisco nei campi della SELECT anche quello che contiene il testo, ci vogliono ben 23 secondi, se invece eseguo la selezione senza neanche un secondo!!!
Fai anche WHERE sul campo testo oppure lo aggiungi semplicemente alle colonne restituite?
[edit]
Nel secondo caso potrebbe essere un problema di performance sì: se hai in media 10K di testo in ogni riga allora ci vuole un po' per prelevare da disco più di 60 mega di dati ;) |
| Drake83 |
provo a dare il mio contributo anche se non so quanto possa servire ( :asd: ) :
1) hai provato ad indicizzare le tabelle ?
2) concordo con yeah: di solito l'uso join non necessita il where. |
| ripe |
Originally posted by yeah
Fai anche WHERE sul campo testo oppure lo aggiungi semplicemente alle colonne restituite?
[edit]
Nel secondo caso potrebbe essere un problema di performance sì: se hai in media 10K di testo in ogni riga allora ci vuole un po' per prelevare da disco più di 60 mega di dati ;)
Si, è proprio questo secondo caso, e c'è parecchio testo in ogni riga...
Quindi c'è ben poco da fare mi sa... mmmmm :sad:
Si Drake, ho degli indici sulle tabelle, per i campi su cui specifico degli ordinamenti... ma non è che le prestazioni ne abbiano ricavato chissà quali benefici!
Grazie a entrambi! :) |
| yeah |
Gli indici servono se fai WHERE / JOIN etc, evitano i table scan, però se devi materialmente recuperare i dati (come nel caso delle colonne delle select) e i dati sono in grande quantità c'è poco da fare.
Originally posted by ripe
C'è qualche soluzione fattibile? Avevo pensato di restituire i record senza il grosso campo di testo, per poi recuperarlo in un secondo momento con un'altra query quando richiesto. Ma non mi piace perchè mi sa molto di workaround...
Probabilmente è la soluzione migliore :)
[edit]
Oppure metti tanti dischi in RAID quanto basta a saturare la banda passante, così dovresti riuscire a minimizzare il tempo della query :asd: |
| Drake83 |
Originally posted by yeah
C'è qualche soluzione fattibile? Avevo pensato di restituire i record senza il grosso campo di testo, per poi recuperarlo in un secondo momento con un'altra query quando richiesto. Ma non mi piace perchè mi sa molto di workaround...
Probabilmente è la soluzione migliore :)
Sì è vero è la soluzione migliore se poi nell'altra query puoi ricercare più nello specifico altrimenti il problema si ripropone. Ci vorrebbe un esperto di tuning di basi di dati e purtroppo quest'esame non l'ho seguito :D |
| ripe |
Nell'altra query posso recuperare il singolo record, quindi forse sì... dovrei orientarmi verso questa direzione...
:D |
| Drake83 |
Originally posted by ripe
Nell'altra query posso recuperare il singolo record, quindi forse sì... dovrei orientarmi verso questa direzione...
:D
ah se puoi secondo me è la soluzione + facile e + conveniente :D |
| ripe |
RISOLTO!!!!!!!!!!!
Mi avete messo sulla buona strada, e studiando meglio la query ho trovato la soluzione!
In pratica eseguo la ricerca dei 10 record per la paginazione prelevando i dati dalla tabella alleggerita ed eseguo il join con i 10 campi di testo pesante solo alla fine.
Ora è una scheggia!
Grazie a chi mi ha dato una mano! |
|
|
|
