Just nu i M3-nätverket
Gå till innehåll

Recordset och StoredProcedures i SQL Server


Racek

Rekommendera Poster

Jag har en procedur som visar ett sökresultat, sorterat med hjälp av en icke primärnyckel kolumn och baserat på 50.000 rader från tre tabeller.

Klienten (på www) visar första 20 rader och användaren kan begära Nästa 20.

Jag försökte på två olika sätt

1. SELECT TOP 20 ... och kom ihåg första och sista sorteringsbegrepp. Vid nästa komletteras WHERE med sorteringsbegreppet.

2. SELECT görs utan begränsning (utan TOP 20) och med hjälp av adodb.recordset i asp använder jag absolutpage att gå fram vid Nästa 20.

 

Kan någon förklara för mig varför är det anra sättet så mycket snabbare?

Länk till kommentar
Dela på andra webbplatser

Hej,

 

Det är lite svårt att se eftersom du inte bifogar någon kod men rent instinktivt känns det som om att datat cachas av SQL servern eftersom du i alt. 2 ställer samma fråga varje gång, därför kan resultatet chachas upp.

 

Vid alt. 1 görs först samma sökning som i steg 2, men här ver inte databasen om att samma data kan återanvändas.

 

Första gången frågorna körs borde alt 1 vara snabbast.

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

Data cachas vid 1 och 2... Fråga 1 är inte snabbare första gången - om du tänker efter - görs samma sak i 1 och 2. För att få 20 första rader måste ändå någon slags resultat skapas och sorteras. Frågan är hur kan ASP hitta till gamla resultatet och undvika köra andra gången.

 

Länk till kommentar
Dela på andra webbplatser

Nu är jag inte säker men så här låter vettig:

 

När du gör en SELECT TOP ... så måste resultatet först sorteras sedan plockas den 20 först posterna ut, alltså görs ingen prestanda vinst mot SELECT ...

 

Om du sedan i nästa fråga tar ut 20-40 så måste de 20 första tas bort med en subfråga. Detta tar tid vilket du inte behöver med en SELECT ...

 

Alltså får du en tidsvinst där.

 

Sedan så tycker man att det borde ta längre tid med rs.absolutpage, eftersom recordsetet måste hämta mer data, men det gör det inte, utan recordset kollar på servern och ser att de 20 första posterna inte skall hämtas utan det endast skall hämtas postern 20-40.

 

Vilket gör att det inte tar mycket längre tid än att endast hämta de 20 poster som SELECT TOP .... ger tillbaka.

 

Så tidsvinster blir att du slipper den extrafråga som måste ta bort den 20 först posterna.

 

Men som sagt, det finns säkert någon med en bättre förklaring.

 

- Magnus

-----------------------------------------------------

ju mer jag lär mig ju mer inser jag så lite jag kan

 

Länk till kommentar
Dela på andra webbplatser

rs.absolutpage hämtar bara så mycket som du säger i pagesize. Jag misstänker att ASP hittar resultat av den gamla frågan od använder sig av det, hittar det inget genomförs en ny sökning. Men allt är vilda gissningar....

 

Länk till kommentar
Dela på andra webbplatser

Hej!

---

"Data cachas vid 1 och 2... Fråga 1 är inte snabbare första gången - om du tänker efter - görs samma sak i 1 och 2. För att få 20 första rader måste ändå någon slags resultat skapas och sorteras. Frågan är hur kan ASP hitta till gamla resultatet och undvika köra andra gången."

---

Jag vidhåller fortfarande att det är svårt att kommentera eftersom du inte bifogat någon kod. SQL kod är något av det snårigaste att diskutera om man inte visar exakt vad som görs eftersom så många mindre uppenbara faktorer spelar in.

 

Båda satserna resulterar i en table-scan eftersom du i första anropet inte anger några begränsningar. Vid andra anropet borde alt 1 vara mycket snabbare. Eftersom du inte bifogat någon kodsnutt eller beskrivit hur ditt ADO anrop är strukturerat, är det svårt att kommentera ASP delen. ASP delen är helt beroende av vilken typ av cursor du använder dig av. Om du har en client-side cursor kommer alt 1 att endast returnera 20 poster. Alt 2 kommer att returnera 50.000 poster, vilket är mycket mer data. Hur ser din pagineringsfunktion ut? Posta ASP delen eller beskriv den.

 

Sedan en kommentar till Magnus inlägg: Typen av cursor är avgörande för prestandan av att använda paginering via ADOs PageSize eftersom denna agerar på resultatsets nivå. Om cursorn finns på servern, kan pagineringen ske där, i annat fall hämtas samtliga 50.000 poster till klienten.

 

För bästa prestanda är Magnus lösning att föredra, så länge cursorn läggs på SQL servern.

 

/foo

 

Länk till kommentar
Dela på andra webbplatser

Jag kan inte visa kundens struktur. Det är klart att allt händer på server sida och att det skulle märkas med client-side cursor. Själva frågan är korrekt. Den söker med hjälp av en icke unik index och sorterar på en unik index (men inte primänyckel och inte clusterindex). Vi har inga problem med prestanda, men jag märkte skillnaden i svarstiderna som verkar ologisk. Alltså: jag undrar om Microsoft på något sätt buffrar en konkret fråga med numrerade resultatrader Så att man i fall att resultat finns kvar i minnet slippa inte bara sökning /den sker i alla fall i bufferten/ utan även sortering. Av intresse kan vara att vi använder Dirty read.

 

Länk till kommentar
Dela på andra webbplatser

Arkiverat

Det här ämnet är nu arkiverat och är stängt för ytterligare svar.

×
×
  • Skapa nytt...