Halaman senarai yang laju dengan sepuluh rekod boleh menjadi perlahan dengan seribu rekod. Kadang-kadang masalahnya bukan satu query besar, tetapi banyak query kecil yang dipanggil satu demi satu ketika setiap item dipaparkan. Pola ini mudah terlepas jika kita hanya menguji dengan data kosong.
Mulakan dengan melihat log query dan masa respons pada dataset yang hampir dengan keadaan sebenar. Jika setiap item memuat hubungan yang sama secara berasingan, pilih data yang diperlukan dengan projection atau loading yang sesuai. Jangan memuat seluruh jadual dan menapisnya di memori jika pangkalan data boleh menapis lebih awal. Pada masa sama, jangan menambah indeks secara rawak tanpa melihat query yang benar-benar lambat.
Uji hasil, bukan hanya bilangan query
Kurang query tidak semestinya automatik lebih cepat jika satu query menjadi terlalu besar. Ukur masa, saiz data dan penggunaan memori. Dokumentasi Microsoft tentang prestasi EF Core memberi contoh cara memilih data dan mengelakkan masalah N+1. Gunakan contoh itu sebagai asas, kemudian ukur pada aplikasi sendiri.
Ambil satu halaman yang terasa lambat dan catat bilangan rekod serta masa respons sebelum mengubah query. Selepas pembaikan, ukur semula dengan data yang sama. Jika tiada perubahan nyata, mungkin punca lain seperti gambar besar atau API luar lebih penting. Ukuran sebelum dan selepas mengelakkan optimasi berdasarkan tekaan.
Apabila membaiki, semak juga paparan pengguna: adakah pagination diperlukan? Adakah semua medan perlu muncul sekaligus? Kadang-kadang penyelesaian terbaik menggabungkan query yang lebih baik dengan pengalaman membaca yang lebih ringkas.