Las páginas se leen en la memoria según sea necesario, si no hay memoria libre disponible, la página más antigua no modificada se reemplaza por la página entrante.
Esto significa que si ejecuta una consulta que requiere más datos de los que caben en la memoria, muchas páginas vivirán una vida muy corta en la memoria, lo que generará muchas E / S.
Puede ver este efecto mirando el contador "Esperanza de vida de la página" en el Monitor de rendimiento de Windows. Mire https://sqlperformance.com/2014/10/sql-performance/knee-jerk-page-life-expectancy para obtener algunos detalles excelentes sobre ese contador.
En los comentarios, usted preguntó específicamente qué sucede cuando los resultados de la consulta son mayores que el espacio disponible en el búfer. Tome el ejemplo más simple select * from some_very_big_table;: suponga que la tabla tiene 32 GB y max server memory (MB)está configurada en 24 GB . Todos los 32 GB de datos de la tabla se leerán en páginas en el búfer de la página, una a la vez, enclavadas, formateado en paquetes de red y enviado a través del cable. Esto sucede página por página; podría tener 300 consultas de este tipo ejecutándose al mismo tiempo, y suponiendo que no ocurriera ningún bloqueo, los datos de cada consulta se leerían en el espacio de búfer de la página, una página a la vez, y se colocarían en el cable tan rápido como el cliente pueda solicitar y consumir los datos. Una vez que todos los datos de cada página se han enviado al cable, la página se desbloquea y será reemplazada rápidamente por alguna otra página del disco.
En el caso de una consulta más compleja, por ejemplo, agregando resultados de varias tablas, las páginas se extraerán a la memoria exactamente como se indica arriba según lo requiera el procesador de consultas. Si el procesador de consultas necesita espacio de trabajo temporal para calcular los resultados, lo sabrá por adelantado cuando compile un plan para la consulta y solicitará espacio de trabajo (memoria) a SQLOS . SQLOS en algún momento (suponiendo que no se agote el tiempo de espera ), otorgará esa memoria al procesador de consultas, momento en el que se reanudará el procesamiento de consultas. Si el procesador de consultas comete un error al calcular la cantidad de memoria que debe solicitar SQLOS, es posible que deba realizar un "derrame al disco"operación, donde los datos se escriben temporalmente en tempdb en una forma intermedia. Las páginas que se han escrito en tempdb se desbloquean una vez que se escriben en tempdb para dejar espacio para que otras páginas se lean en la memoria. Eventualmente, el proceso de consulta volverá a los datos almacenados en tempdb, paginado al usar el enclavamiento, en páginas en el búfer que están marcadas como libres.
Indudablemente, me falta una carga de detalles muy técnicos en el resumen anterior, pero creo que captura la esencia de cómo SQL Server puede procesar más datos de los que caben en la memoria.