İçeriğe geç

SQL Server’da Index Fragmentation Kontrolü ve Reorganize

Index'ler zamanla parçalanır ve performans kaybeder. Parçalanma oranını SSMS ve T-SQL ile nasıl ölçeceğinizi, reorganize ile rebuild arasındaki farkı anlatıyorum.

SQL Server güncellendi 25.10.2026 3 dk okuma Atılay Berber

Merhabalar,

Bu yazıda SQL Server’daki tabloların index’lerinde oluşan fragmentation (parçalanma) oranını nasıl kontrol edeceğimize ve parçalanmış index’leri nasıl reorganize edeceğimize bakacağız.

Yazdığımız T-SQL sorgularının performansını etkileyen en önemli unsurlardan biri index’lerdir. Index’leri, belirlediğimiz alanlardaki verilere göre hazırlanmış bir fihrist gibi düşünebiliriz. Bir tablodaki x alanına index tanımladıysak, o alanda arama yapmak ya da başka bir tabloyla join yapmak çok daha hızlı olur. Index’lerin clustered ve nonclustered olmak üzere iki temel tipi vardır.

Tablolar sürekli INSERT, UPDATE ve DELETE işlemlerine maruz kaldığı için zamanla index sayfaları da parçalanır. Bunu bilgisayarımızdaki diskte dosyaların parçalanmasına ve disk birleştirme (defrag) ihtiyacına benzetebiliriz. Parçalanan index’ler zamanla performans kaybetmeye başlar.

Index’lerin fragmentation oranını belirlemek

1. SSMS üzerinden: Kontrol etmek istediğiniz veritabanında Tables altından ilgili tabloyu açın ve Indexes klasöründeki index’i bulun.

SSMS'te tablo altındaki index listesi

Index’e sağ tıklayıp Properties (Özellikler) penceresini açın; Fragmentation sayfasında parçalanma oranını görebilirsiniz.

Index özellikleri penceresinde fragmentation bilgisi

2. T-SQL ile: Bir veritabanındaki tüm tabloların index’lerini parçalanma oranına göre listelemek için sys.dm_db_index_physical_stats fonksiyonunu kullanabiliriz:

SELECT dbtables.[name]                                     AS [Table],
       dbindexes.[name]                                    AS [Index],
       ROUND(indexstats.avg_fragmentation_in_percent, 3)   AS Fragmentation,
       indexstats.record_count,
       indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(N'Database_Adi'), NULL, NULL, NULL, 'SAMPLED') AS indexstats
INNER JOIN sys.tables AS dbtables
        ON dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.indexes AS dbindexes
        ON dbindexes.[object_id] = indexstats.[object_id]
       AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID(N'Database_Adi')
  AND indexstats.avg_fragmentation_in_percent > 30
ORDER BY indexstats.avg_fragmentation_in_percent DESC;

WHERE koşulundaki avg_fragmentation_in_percent > 30 ifadesi, parçalanma oranı %30’un üzerinde olan index’leri getirir. Çok küçük tablolarda (birkaç yüz sayfanın altında) yüksek oranlar genellikle performansı etkilemez; bu yüzden page_count sütununa da bakmakta fayda var.

Parçalanmış index’leri reorganize etmek

Index’leri reorganize etmenin birçok yolu var; ben iki tanesine değineceğim.

1. SSMS üzerinden: Index’e sağ tıklayıp Reorganize seçeneğini seçin. Açılan Reorganize Indexes ekranında OK düğmesine basarak işlemi başlatabilirsiniz.

Index sağ tık menüsünde Reorganize seçeneği
Reorganize Indexes penceresi

2. T-SQL ile: Belirli bir index’i ya da bir tablodaki tüm index’leri reorganize edebilirsiniz.

-- Tablodaki belirli bir index'i reorganize etmek
USE [Database_Adi];
GO
ALTER INDEX [Index_Adi] ON [dbo].[Table_Adi] REORGANIZE;
GO

-- Tablodaki tüm index'leri reorganize etmek
ALTER INDEX ALL ON [dbo].[Table_Adi] REORGANIZE;
GO

Reorganize mi, rebuild mı?

REORGANIZE çevrimiçi ve hafif bir işlemdir; index’in yaprak seviyesini yerinde düzenler ve istenirse yarıda kesilebilir. REBUILD ise index’i baştan oluşturur; daha kapsamlıdır ama daha fazla kaynak kullanır ve Enterprise sürüm dışında tabloyu işlem boyunca kilitleyebilir. Yaygın kullanılan pratik kural, orta seviyedeki parçalanmada reorganize, yüksek parçalanmada rebuild tercih etmektir. Yine de eşikleri körü körüne uygulamak yerine, bakımın sorgu performansına gerçekten etkisini ölçmek en doğrusudur.

ALTER INDEX [Index_Adi] ON [dbo].[Table_Adi] REBUILD;

Sık yapılan hatalar

  • Her gece her şeyi rebuild etmek: Gereksiz rebuild, log dosyasını şişirir, yedeklemeyi ve kopyalamayı yavaşlatır, bakım penceresini uzatır. Yalnızca gerçekten parçalanmış ve yeterince büyük index’lere dokunun.
  • İstatistikleri unutmak: REORGANIZE istatistikleri güncellemez; REBUILD ise ilgili index’in istatistiğini tam taramayla günceller. Reorganize sonrası gerekirse UPDATE STATISTICS çalıştırın.
  • Sadece yüzdeye bakmak: Sayfa doluluğu (avg_page_space_used_in_percent) da önemlidir. Yarı boş sayfalar daha fazla okuma ve bellek demektir. Bu sütun SAMPLED ya da DETAILED modunda gelir.
  • Fill factor’ı gereksiz düşük tutmak: Çok düşük fill factor sayfaları baştan boş bırakır ve okuma maliyetini artırır. Sadece sık sayfa bölünmesi yaşanan index’lerde düşürün.

Sık sorulan sorular

SSD disklerde fragmentation hâlâ önemli mi?

Sayfaların disk üzerindeki sırası SSD’lerde eskisi kadar önemli değil. Ama sayfa doluluğu hâlâ önemli: düşük doluluk, aynı veriyi okumak için daha fazla sayfa ve daha fazla bellek kullanmak demek. Bu yüzden ölçmeye devam edin, ama bakımı otomatik değil ihtiyaca göre yapın.

Bakımı otomatikleştirmenin pratik yolu nedir?

Yaygın tercih, Ola Hallengren’in ücretsiz bakım çözümündeki IndexOptimize yordamını SQL Server Agent ile zamanlamaktır. Eşikleri ve sayfa sayısı sınırını parametreyle verebilirsiniz. Enterprise sürümde REBUILD WITH (ONLINE = ON) ile tabloyu kilitlemeden yeniden oluşturmak da mümkündür.

İlgili yazılar

HABERDAR OL

Yeni rehberler, kategorilere ayrılmış tek bir e-postada.

Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.

Onay e-postasındaki bağlantıya tıklamadan liste aktif olmaz. İstediğin an tek tıkla çıkabilirsin.

Faydalı bulduysan paylaş
LinkedIn'de paylaş X WhatsApp

Yorum yaz

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir