SQL Server'da Yavaş Sorgu Nasıl Bulunur? 7 Adımda Performans Analizi
Mehmet Fatih İçin · · 8 dk okuma
Kurumsal sistemlerde “sistem yavaş” şikâyetinin büyük çoğunluğu birkaç kötü sorgudan kaynaklanır. 15 yılı aşkın süredir biletleme, ERP ve entegrasyon veritabanlarında uyguladığım yaklaşım şu: tahmin etme, ölç.
1. En pahalı sorguları DMV ile bul
SELECT TOP 20
qs.total_worker_time / qs.execution_count AS avg_cpu_us,
qs.total_logical_reads / qs.execution_count AS avg_reads,
qs.execution_count,
SUBSTRING(st.text, qs.statement_start_offset/2 + 1,
(CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2 + 1) AS sql_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY qs.total_worker_time DESC;
Toplam CPU'ya göre sıralamak, tek seferde yavaş olan sorgu yerine sisteme en çok yük bindiren sorguyu öne çıkarır. Çoğu zaman milisaniyeler süren ama dakikada binlerce kez çalışan bir sorgu asıl suçludur.
2. Query Store'u aç
SQL Server 2016 ve sonrasında Query Store, sorgu planlarını ve süreleri zaman içinde saklar. “Dün hızlıydı, bugün yavaş” sorununu, hangi plan değişikliğinin bozduğunu göstererek çözer. Gerektiğinde iyi planı zorlayabilirsin.
3. Çalışma planını oku
Gerçek çalışma planında şu işaretlere bak: büyük tablolarda Index Scan, tahmini ve gerçek satır sayısı arasında büyük farklar, Key Lookup döngüleri, uyarı ikonları (implicit conversion, spill to tempdb).
4. Eksik index önerilerini dikkatle değerlendir
sys.dm_db_missing_index_details faydalı ipuçları verir ama her öneriyi körü körüne uygulama. Fazla index yazma işlemlerini yavaşlatır. Benzer önerileri tek bir kapsayan (covering) index'te birleştir.
5. Tür uyuşmazlıklarını yakala
NVARCHAR parametreyle VARCHAR kolon karşılaştırmak, index'i kullanılmaz hale getirebilir. Uygulama katmanında (ORM, Dapper, ADO.NET) parametre türlerini kolon türleriyle eşleştir.
6. Parametre koklama (parameter sniffing)
Aynı sorgu bazı parametrelerle çok hızlı, bazılarıyla çok yavaşsa ilk derlenen plan diğer değerler için kötü olabilir. Seçenekler: OPTION (RECOMPILE), OPTIMIZE FOR, sorguyu bölmek ya da Query Store ile plan zorlamak.
7. İstatistikleri ve bakımı unutma
Güncel olmayan istatistikler yanlış plan seçimine neden olur. Büyük veri yüklemelerinden sonra istatistikleri güncelle, düzenli bir bakım planı kur.
Destek mi lazım?
Yavaşlayan bir SQL Server veya Oracle veritabanı için performans analizi ve iyileştirme desteği veriyorum. Hizmetler sayfasından teklif isteyebilirsin.