Når du udfører din forespørgsel, læses dataene ind i hukommelsen i blokke. Disse blokke forbliver i hukommelsen, men de bliver "ældet". Dette betyder, at blokkene er tagget med den sidste adgang, og når SQL Server kræver en anden blok for en ny forespørgsel, og hukommelsescachen er fuld, bliver den mindst brugte blok (den ældste) smidt ud af hukommelsen. (I de fleste tilfælde - scanningsblokke for fulde tabeller ældes øjeblikkeligt for at forhindre, at scanninger af fulde tabeller overskrider hukommelsen og kvæler serveren).
Det, der sker her, er, at datablokkene i hukommelsen fra den første forespørgsel endnu ikke er blevet smidt ud af hukommelsen, så de kan bruges til din anden forespørgsel, hvilket betyder, at diskadgang undgås, og ydeevnen forbedres.
Så det, dit spørgsmål i virkeligheden stiller, er "kan jeg få de datablokke, jeg har brug for, ind i hukommelsen uden at læse dem ind i hukommelsen (faktisk lave en forespørgsel)?". Svaret er nej, medmindre du vil cache hele tabellerne og have dem permanent i hukommelsen, hvilket ud fra den forespørgselstid (og dermed datastørrelsen), du beskriver, sandsynligvis ikke er en god idé.
Dit bedste bud på forbedring af ydeevnen er at se på dine planer for udførelse af forespørgsler og se, om ændring af dine indekser kan give et bedre resultat. Der er to hovedområder, der kan forbedre ydeevnen her:
- oprettelse af et indeks, hvor forespørgslen kunne bruge et til at undgå ineffektive forespørgsler og fulde tabelscanninger
- tilføjelse af flere kolonner til et indeks for at undgå en ny disklæsning. For eksempel har du en forespørgsel, der returnerer kolonne A og B med en where-klausul på A og C, og du har et indeks i kolonne A. Din forespørgsel vil bruge indekset for kolonne A, der kræver én disk, men kræver derefter en anden disk hit for at få kolonne B og C. Hvis indekset havde alle kolonner A, B og C i sig, kan det andet diskhit for at hente data undgås.