Detaljerna är implementeringsberoende men allmänt sett, resultaten buffras. Att köra en fråga mot en databas kommer att returnera en viss resultatuppsättning. Om det är tillräckligt litet kan alla resultat returneras med det första anropet eller så kan vissa bli det och fler resultat returneras när du itererar över resultatobjektet.
Tänk på sekvensen så här:
- Du öppnar en anslutning till databasen;
- Det finns möjligen ett andra anrop för att välja en databas eller så kan det göras som en del av (1);
- Autentiserings- och anslutningssteget är (minst) en tur och retur till servern (ignorering av beständiga anslutningar);
- Du kör en fråga på klienten;
- Frågan skickas till servern;
- Servern måste bestämma hur frågan ska köras;
- Om servern tidigare har kört frågan kan exekveringsplanen fortfarande finnas i frågecachen. Om inte måste en ny plan skapas;
- Servern kör frågan som given och returnerar ett resultat till klienten;
- Det resultatet kommer att innehålla någon buffert med rader som är implementeringsberoende. Det kan vara 100 rader eller fler eller färre. Alla kolumner returneras för varje rad;
- När du hämtar fler rader så kommer klienten att be servern om fler rader. Det kan vara när klienten tar slut eller så kan det ske förebyggande. Återigen är detta implementeringsberoende.
Tanken med allt detta är att minimera tur och retur till servern utan att skicka tillbaka för mycket onödig data, vilket är anledningen till att om du ber om en miljon rader kommer du inte att få tillbaka alla på en gång.
LIMIT-klausuler - eller vilken klausul som helst - kommer att ändra resultatuppsättningen.
Slutligen är (7) viktigt eftersom SELECT * FROM table WHERE a = 'foo' och SELECT * FROM table WHERE a = 'bar' är två olika frågor när det gäller databasoptimeraren, så en exekveringsplan måste fastställas för varje separat. Men en parametriserad fråga (SELECT * FROM table WHERE a = :param ) med olika parametrar är en fråga och behöver bara planeras en gång (åtminstone tills den faller ur frågecachen).