Veritabanı Index Yönetimi: Görünmez Değişiklik Riski
I’m a passionate software engineer specializing in SQL change management, database security, and DevOps automation. With over 17 years of experience in the banking sector, I focus on building tools and processes that make database deployments safer, more auditable, and automated.
As the creator of SQL Change Guard, I develop solutions that use risk scoring and AI-powered code analysis to detect dangerous SQL scripts before they reach production. I’m dedicated to helping teams minimize downtime and data loss through smarter change governance.
When I’m not coding, I enjoy sharing insights about secure development practices, WPF desktop applications, and integrating modern CI/CD pipelines.
Feel free to connect or reach out at info@sqlchangeguard.com
Index eklemek veya kaldırmak zararsız bir operasyon gibi görünür. Ama yanlış zamanda ya da yanlış şekilde yapıldığında production'ı ciddi biçimde etkileyebilir.
Index Değişikliği Neden Risk Taşır? Index, sorgu performansını doğrudan etkiler. Bir index eklendiğinde bazı sorgular hızlanır, bazıları yavaşlayabilir. Bir index kaldırıldığında tam tersi olur. Bu dengeyi öngörmek çoğu zaman zordur. Bunun dışında index operasyonlarının kendisi de risk taşır: Tablo kilitleme: Büyük bir tabloda index oluşturmak ya da yeniden oluşturmak tabloyu kilitleyebilir. Bu süreçte tabloya erişmeye çalışan sorgular bekler ya da timeout alır. Disk ve CPU yükü: Index operasyonları yoğun I/O ve CPU kullanır. Yanlış zamanda yapılırsa sistem genelini etkiler.
En Sık Yapılan Hatalar Yanlış saatte index rebuild Geliştirici performans sorununu fark etti, index rebuild başlattı. Saat 14:00, sistem yoğun. Tablo kilitlendi, onlarca sorgu beklemeye geçti. Müşteri şikayetleri başladı. Test edilmeden production'a index ekleme "Bu index sorguyu hızlandırır" diye test ortamında denenmeden production'a eklendi. Evet, hedef sorgu hızlandı. Ama aynı tabloyu kullanan başka bir sorgu sorgu planını değiştirdi ve yavaşladı. Kullanılmayan index birikimi Zaman içinde ihtiyaç kalmayan indexler kaldırılmadı. Her index INSERT ve UPDATE işlemlerini yavaşlatır. Tabloda onlarca gereksiz index olduğunda yazma performansı ciddi biçimde düşer.
Index Değişikliği Öncesi Kontroller Yeni index eklemeden önce şunları kontrol edin: Bu index zaten var mı? Benzer bir index mevcut değil mi? sqlSELECT i.name AS IndexAdi, i.type_desc AS IndexTipi, STRING_AGG(c.name, ', ') AS Kolonlar FROM sys.indexes i JOIN sys.index_columns ic ON i.object_id = ic.object_id AND i.index_id = ic.index_id JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id WHERE i.object_id = OBJECT_ID('dbo.HedefTablo') GROUP BY i.name, i.type_desc ORDER BY i.name; Bu index ne kadar kullanılacak? İlgili sorgu gerçekten yeterli sıklıkta çalışıyor mu? Online operasyon mümkün mü? Enterprise Edition'da ONLINE = ON seçeneği tabloyu kilitlemeden index oluşturur.
Kullanılmayan Index Tespiti sqlSELECT OBJECT_NAME(i.object_id) AS Tablo, i.name AS IndexAdi, ius.user_seeks, ius.user_scans, ius.user_lookups, ius.user_updates FROM sys.indexes i LEFT JOIN sys.dm_db_index_usage_stats ius ON i.object_id = ius.object_id AND i.index_id = ius.index_id AND ius.database_id = DB_ID() WHERE i.type_desc != 'HEAP' AND i.is_primary_key = 0 AND i.is_unique = 0 ORDER BY ISNULL(ius.user_seeks, 0) + ISNULL(ius.user_scans, 0) ASC; Bu sorgu az kullanılan index'leri listeler. Kaldırma kararı vermeden önce SQL Server'ın son restart'ından bu yana ne kadar süre geçtiğini kontrol edin, çünkü istatistikler restart'ta sıfırlanır.
Sonuç Index değişiklikleri şema değişiklikleri kadar dikkatli yönetilmeli. Test ortamında doğrulama, doğru zamanlama ve etki analizi index operasyonlarını güvenli hale getirir. Detaylı bilgi için: sqlchangeguard.com