Pertama, pastikan Anda membuat profil kinerja dengan benar. Misalnya, jalankan kueri dua kali dari ADO.NET dan lihat apakah yang kedua jauh lebih cepat daripada yang pertama. Ini menghilangkan overhead menunggu aplikasi dikompilasi dan infrastruktur debug meningkat.
Selanjutnya, periksa pengaturan default di ADO.NET dan SSMS. Misalnya, jika Anda menjalankan SET ARITHABORT OFF di SSMS, Anda mungkin mendapati bahwa sekarang berjalan selambat saat menggunakan ADO.NET.
Apa yang saya temukan sekali adalah bahwa SET ARITHABORT OFF di SSMS menyebabkan proc yang disimpan dikompilasi ulang dan/atau statistik yang berbeda digunakan. Dan tiba-tiba baik SSMS dan ADO.NET melaporkan waktu eksekusi yang kira-kira sama.
Untuk memeriksa ini, lihat rencana eksekusi untuk setiap proses, khususnya tabel syscacheobjects. Mereka mungkin akan berbeda.
Menjalankan 'sp_recompile' pada prosedur tersimpan tertentu akan menghapus rencana eksekusi terkait dari cache, yang kemudian memberi SQL Server kesempatan untuk membuat rencana yang mungkin lebih tepat pada eksekusi prosedur berikutnya.
Terakhir, Anda dapat mencoba pendekatan "nuke it from orbit" untuk membersihkan seluruh cache prosedur dan buffer memori menggunakan SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Melakukannya sebelum Anda menguji kueri Anda mencegah penggunaan rencana eksekusi yang di-cache dan cache hasil sebelumnya.
