Halaman dibaca ke dalam memori sesuai kebutuhan, jika tidak ada memori bebas yang tersedia, halaman tertua yang tidak dimodifikasi diganti dengan halaman yang masuk.
Ini berarti jika Anda menjalankan kueri yang membutuhkan lebih banyak data daripada yang dapat ditampung dalam memori, banyak halaman akan hidup sangat singkat di memori, menghasilkan banyak I / O.
Anda dapat melihat efek ini dengan melihat penghitung "Page Life Expectancy" di Windows Performance Monitor. Lihatlah https://sqlperformance.com/2014/10/sql-performance/knee-jerk-page-life-expectancy untuk beberapa detail hebat tentang penghitung itu.
Dalam komentar, Anda bertanya secara spesifik apa yang terjadi ketika hasil kueri lebih besar dari ruang buffer yang tersedia. Ambil contoh paling sederhana, select * from some_very_big_table;- anggap tabelnya 32GB, dan max server memory (MB)dikonfigurasi pada 24GB. Semua 32GB data tabel akan dibaca ke dalam halaman di buffer halaman satu per satu, terkunci, diformat ke dalam paket jaringan, dan dikirim melintasi kawat. Ini terjadi halaman demi halaman; Anda bisa menjalankan 300 permintaan seperti itu pada saat yang sama, dan dengan asumsi tidak ada pemblokiran yang terjadi, data untuk setiap permintaan akan dibaca ke dalam ruang penyangga halaman, satu halaman pada satu waktu, dan dimasukkan ke dalam kawat secepat yang dapat dilakukan klien meminta dan mengkonsumsi data. Setelah semua data dari setiap halaman dikirim ke kabel, halaman menjadi tidak terkunci, dan akan segera diganti oleh beberapa halaman lain dari disk.
Dalam kasus kueri yang lebih kompleks, misalnya untuk agregat hasil dari beberapa tabel, halaman akan ditarik ke memori persis seperti di atas seperti yang diminta oleh prosesor kueri. Jika pemroses kueri membutuhkan ruang kerja sementara untuk menghitung hasil, ia akan tahu bahwa dimuka saat ia menyusun rencana untuk kueri, dan akan meminta ruang kerja (memori) dari SQLOS . SQLOS akan di beberapa titik (dengan asumsi itu tidak time out ), memberikan memori itu ke prosesor permintaan, di mana pemrosesan permintaan titik akan dilanjutkan. Jika pemroses kueri membuat kesalahan dalam memperkirakan berapa banyak memori yang diminta dari SQLOS, mungkin perlu melakukan "tumpahan ke disk"operasi, di mana data sementara ditulis ke tempdb dalam bentuk peralihan. Halaman-halaman yang telah ditulis ke tempdb akan tidak terkunci setelah mereka ditulis ke tempdb untuk memberikan ruang bagi halaman-halaman lain untuk dibaca ke dalam memori. Akhirnya proses permintaan akan kembali ke data yang disimpan di tempdb, paging yang menggunakan kait, ke halaman di buffer yang ditandai bebas.
Saya pasti melewatkan banyak detail yang sangat teknis dalam ringkasan di atas, tapi saya pikir itu menangkap esensi dari bagaimana SQL Server dapat memproses lebih banyak data daripada yang dapat ditampung dalam memori.