T-SQL Ayarında Neden Okumalar Önemlidir? Logical Reads, STATISTICS IO ve Index’ler

Bir sorguyu hızlandırmaya çalışırken en çok bakılan ölçü genellikle süredir. Ama süre güvenilmez bir ölçüdür: aynı sorgu, sunucunun o anki yüküne, verinin bellekte olup olmamasına ve başka sorguların kilitlerine göre her çalıştırmada farklı süre alır. Daha kararlı ve daha açıklayıcı bir ölçü vardır: sorgunun okuduğu sayfa sayısı.

SQL Server veriyi 8 KB’lık sayfalar halinde okur. Bir sorgunun okuduğu sayfa sayısı; harcadığı CPU’yu, kullandığı belleği ve bellekte yer yoksa diske yaptığı erişimi doğrudan belirler. Bu yazıda okumaları nasıl ölçeceğinizi, logical ve physical okumanın farkını ve okumaları azaltarak sorguları nasıl hızlandıracağınızı anlatıyoruz.

Okumaları Ölçmek: STATISTICS IO

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT SiparisNo, Tutar
FROM dbo.Siparis
WHERE MusteriId = 1001;

SSMS’in Messages sekmesinde her tablo için şöyle bir satır görürsünüz:

• logical reads: Sorgunun bellekten (buffer pool) okuduğu sayfa sayısı. Tuning’in ana ölçüsü budur.
• physical reads ve read-ahead reads: Bellekte bulunmadığı için diskten okunan sayfalar. Aynı sorgu ikinci kez çalıştığında genellikle sıfıra iner; bu yüzden tek başına karşılaştırma için kullanılmamalıdır.
• Scan count: Tabloya ya da index’e kaç kez erişildiği.

Yukarıdaki örnekte tek bir müşterinin siparişlerini bulmak için yaklaşık 48.000 sayfa, yani 375 MB’lık veri bellekten okunmuştur. Bu, büyük olasılıkla MusteriId üzerinde bir index olmadığını ve tablonun tamamının tarandığını gösterir.

Neden Logical Reads?

• Kararlıdır: Aynı veri ve aynı planla her çalıştırmada aynı sayıyı verir; sunucunun anlık yükünden etkilenmez. Bu yüzden önce/sonra karşılaştırması için idealdir.
• CPU ile ilişkilidir: Okunan her sayfanın işlenmesi CPU harcar. Okumaları azaltmak çoğu zaman CPU’yu da düşürür.
• Belleği korur: Gereksiz yere okunan sayfalar buffer pool’u doldurur ve başka sorguların ihtiyaç duyduğu verilerin bellekten atılmasına, yani onların disk okumasına yol açar.
• Diske yansır: Bellek yetmediğinde logical reads’in bir kısmı physical reads’e dönüşür; disk, sistemin en yavaş katmanıdır.

Okumaları Azaltmanın Yolları

1. Doğru index

Filtre ve join kolonlarında uygun bir index, tablonun tamamını taramak yerine yalnızca ilgili sayfalara gitmeyi (index seek) sağlar. Sorgunun döndürdüğü kolonlar da index’e INCLUDE ile eklenirse, ana tabloya geri dönme (key lookup) ihtiyacı da ortadan kalkar:

CREATE NONCLUSTERED INDEX IX_Siparis_MusteriId
ON dbo.Siparis (MusteriId)
INCLUDE (SiparisNo, Tutar);

Bu index’ten sonra aynı sorgunun okumaları genellikle onlarca binlerden tek ya da çift haneli sayılara iner. Index tasarımının ayrıntıları için index rehberimize bakın.

2. Yalnızca gereken kolonlar

SELECT *, index’in tüm kolonları kapsamasını imkânsız hale getirir ve gereksiz LOB okumalarına yol açabilir. Uygulamanın gerçekten kullandığı kolonları seçin.

3. SARGable koşullar

Kolonu bir fonksiyonun içine almak (örneğin YEAR(Tarih) = 2026) index’in kullanılmasını engeller ve tarama yaptırır. Ayrıntılar WHERE koşulunda tarih hesabı yazımızda.

4. Güncel istatistikler

Optimizer, kaç satır döneceğini istatistiklerden tahmin eder. Eskimiş istatistikler, az satır için tarama ya da çok satır için iç içe döngü gibi yanlış plan seçimlerine ve gereksiz okumalara yol açar.

5. Satır satır işlem yerine küme tabanlı işlem

Cursor ya da döngü içinde her satır için ayrı sorgu çalıştırmak, aynı sayfaları tekrar tekrar okur. Tek bir küme tabanlı ifade çok daha az okumayla aynı işi yapar.

En Çok Okuma Yapan Sorguları Bulmak

SELECT TOP (20)
       qs.total_logical_reads,
       qs.execution_count,
       qs.total_logical_reads / qs.execution_count AS avg_logical_reads,
       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 statement_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_logical_reads DESC;

Daha kapsamlı bir yaklaşım için yavaş sorguları bulma rehberimize bakın.

Kontrol Listesi

• Tuning öncesi ve sonrası STATISTICS IO ile logical reads ölçülüyor.
• Karşılaştırmada süre yerine logical reads ve CPU time kullanılıyor.
• Filtre ve join kolonlarında uygun index’ler var; gerekli kolonlar INCLUDE ile kapsanıyor.
• SELECT * ve SARGable olmayan koşullar temizlendi.
• En çok okuma yapan sorgular düzenli olarak gözden geçiriliyor.