Veritaban\u0131 indeksleme, sorgu performans\u0131n\u0131 art\u0131rman\u0131n temel ta\u015flar\u0131ndan biridir; ancak “daha fazla indeks daha h\u0131zl\u0131d\u0131r” yan\u0131lg\u0131s\u0131, optimize etti\u011finizi d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fcz sorgular\u0131 beklenmedik bir \u015fekilde yava\u015flatabilir. Bu makale, indekslemenin inceliklerini ve do\u011fru stratejilerle veritaban\u0131 performans\u0131n\u0131z\u0131 nas\u0131l zirveye ta\u015f\u0131yaca\u011f\u0131n\u0131z\u0131 a\u00e7\u0131kl\u0131yor.<\/p>\n
Veritaban\u0131 indeksleme, veritaban\u0131 sistemlerinin belirli s\u00fctunlardaki verilere daha h\u0131zl\u0131 eri\u015fmesini sa\u011flayan bir optimizasyon tekni\u011fidir. Bunu, b\u00fcy\u00fck bir kitab\u0131n arkas\u0131ndaki alfabetik dizine benzetebiliriz. Bir kitapta belirli bir konuyu bulmak i\u00e7in her sayfay\u0131 tek tek okumak yerine, dizine bakarak ilgili sayfa numaras\u0131na do\u011frudan gidebiliriz. \u0130\u015fte indeksler de veritabanlar\u0131 i\u00e7in tam olarak bu i\u015flevi g\u00f6r\u00fcr; sorgular\u0131n, aranan verilere \u00e7ok daha az disk I\/O (giri\u015f\/\u00e7\u0131k\u0131\u015f) i\u015flemiyle ula\u015fmas\u0131n\u0131 sa\u011flarlar.<\/p>\n
\u0130ndeksler genellikle B-Tree (B-A\u011fac\u0131) yap\u0131s\u0131nda organize edilir ve bu yap\u0131, veritaban\u0131 y\u00f6neticileri taraf\u0131ndan en yayg\u0131n kullan\u0131lan dizin t\u00fcr\u00fcd\u00fcr. B-Tree indeksler, s\u0131ral\u0131 verilere h\u0131zl\u0131 eri\u015fim, aral\u0131k sorgular\u0131 ve s\u0131ralama i\u015flemleri i\u00e7in idealdir. \u00d6rne\u011fin, bir e-ticaret sitesinde “fiyat\u0131 100 TL ile 200 TL aras\u0131nda olan \u00fcr\u00fcnleri listele” gibi bir sorgu, fiyat s\u00fctununda bir indeks varsa inan\u0131lmaz derecede h\u0131zlan\u0131r. \u0130ndeks olmadan, veritaban\u0131n\u0131n t\u00fcm \u00fcr\u00fcn kay\u0131tlar\u0131n\u0131 taramas\u0131 (tam tablo taramas\u0131) gerekir ki bu, milyonlarca kayd\u0131 olan bir tabloda kabul edilemez derecede yava\u015f olabilir.<\/p>\n
Birincil anahtarlar (Primary Keys) genellikle otomatik olarak indekslenir, \u00e7\u00fcnk\u00fc her sat\u0131r\u0131 benzersiz \u015fekilde tan\u0131mlarlar ve bu s\u00fctunlar \u00fczerinde s\u0131k\u00e7a arama ve birle\u015ftirme (join) i\u015flemleri yap\u0131l\u0131r. Ancak indeksleme sadece birincil anahtarlarla s\u0131n\u0131rl\u0131 de\u011fildir. Yabanc\u0131 anahtarlar (Foreign Keys) ve s\u0131k\u00e7a Evet, indeksler sorgu h\u0131z\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rabilir; ancak madalyonun di\u011fer bir y\u00fcz\u00fc de var. \u00c7o\u011fu zaman geli\u015ftiriciler, “Sorgum yava\u015f \u00e7al\u0131\u015f\u0131yor, bir indeks ekleyeyim” d\u00fc\u015f\u00fcncesiyle hareket eder ve bazen bu, bir \u00e7\u00f6z\u00fcmden ziyade yeni bir soruna yol a\u00e7abilir. Neden mi? \u00c7\u00fcnk\u00fc indeksler bedelsiz de\u011fildir. Her indeksin kendi depolama alan\u0131 maliyeti vard\u0131r. \u00d6zellikle b\u00fcy\u00fck tablolar ve \u00e7ok say\u0131da indeks oldu\u011funda, indeksler diskte \u00f6nemli yer kaplayabilir. Dahas\u0131, bu indeksler bir kez olu\u015fturulduktan sonra, veritaban\u0131ndaki veri de\u011fi\u015fikliklerinde (INSERT, UPDATE, DELETE i\u015flemleri) g\u00fcncel tutulmak zorundad\u0131r.<\/p>\n Her bir Bir di\u011fer \u00f6nemli sorun ise, veritaban\u0131 iyile\u015ftiricisinin (optimizer) karma\u015f\u0131k hale gelmesidir. \u00c7ok fazla indeks oldu\u011funda, iyile\u015ftirici hangi indeksi kullanaca\u011f\u0131na karar vermekte zorlanabilir ve bazen en uygun olmayan indeksi se\u00e7erek sorgunun daha uzun s\u00fcrmesine neden olabilir. Hatta baz\u0131 durumlarda, iyile\u015ftirici, bir indeksi kullanmaktansa tam tablo taramas\u0131n\u0131 (full table scan) tercih edebilir, \u00e7\u00fcnk\u00fc indeksin getirdi\u011fi ek maliyet (\u00f6rne\u011fin, indeksin kendisini okuma ve ard\u0131ndan ana tabloya eri\u015fme maliyeti) tam taramadan daha y\u00fcksek olabilir. Bu t\u00fcr durumlar genellikle d\u00fc\u015f\u00fck veri yo\u011funlu\u011funa sahip indekslerde veya karma\u015f\u0131k sorgularda ortaya \u00e7\u0131kar.<\/p>\n Son olarak, gereksiz indeksler, bir kayna\u011f\u0131n bo\u015f yere t\u00fcketilmesi anlam\u0131na gelir. Veritaban\u0131 y\u00f6neticileri, kullan\u0131l\u0131p kullan\u0131lmad\u0131\u011f\u0131n\u0131 bilmedikleri indeksleri s\u00fcrd\u00fcrmek zorunda kalabilirler. Bu da hem depolama alan\u0131n\u0131n bo\u015fa harcanmas\u0131na hem de potansiyel olarak yazma performans\u0131n\u0131n d\u00fc\u015fmesine yol a\u00e7ar. Bu y\u00fczden, her indeksin bir amac\u0131 olmal\u0131 ve d\u00fczenli olarak izlenerek kullan\u0131m d\u0131\u015f\u0131 kalanlar tespit edilip kald\u0131r\u0131lmal\u0131d\u0131r. Do\u011fru indeksleme stratejisi, sadece performans kazan\u00e7lar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda operasyonel maliyetleri ve sistem karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 da g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131d\u0131r. Bu dengeyi sa\u011flamak, ba\u015far\u0131l\u0131 bir veritaban\u0131 y\u00f6netimi i\u00e7in kritik bir ad\u0131md\u0131r.<\/p>\n Veritaban\u0131 indekslemesinde “do\u011fru” karar\u0131 vermek, sorgu performans\u0131n\u0131 art\u0131rman\u0131n anahtar\u0131d\u0131r. Peki, bu “do\u011fru” indeksler nas\u0131l belirlenir ve olu\u015fturulur? \u0130lk ad\u0131m, veritaban\u0131n\u0131zda en s\u0131k ve en kritik \u015fekilde kullan\u0131lan sorgular\u0131 analiz etmektir. Hangi sorgular yava\u015f \u00e7al\u0131\u015f\u0131yor? Hangi tablolar \u00fczerinde en \u00e7ok arama, filtreleme ve s\u0131ralama yap\u0131l\u0131yor? Bu sorular\u0131n yan\u0131tlar\u0131, indeksleme stratejinizin temelini olu\u015fturacakt\u0131r. Genellikle Sorgu analizi i\u00e7in vazge\u00e7ilmez bir ara\u00e7, veritaban\u0131 sistemlerinin sa\u011flad\u0131\u011f\u0131 sorgu plan\u0131 a\u00e7\u0131klama ara\u00e7lar\u0131d\u0131r. SQL Server'da Bir \u00f6rnekle a\u00e7\u0131klayal\u0131m. Bir e-ticaret uygulamas\u0131nda s\u0131k\u00e7a kullan\u0131lan bir sorgu d\u00fc\u015f\u00fcn\u00fcn:<\/p>\n <\/code><\/p>\n Bu sorguyu optimize etmek i\u00e7in <\/code><\/p>\n Bu indeks, Bir e-ticaret sitesinin <\/code><\/p>\n Bu sorgu i\u00e7in \u00f6nerilen indeks, \u0130ndeks olu\u015fturmak \u00f6nemli bir ba\u015flang\u0131\u00e7 ad\u0131m\u0131d\u0131r, ancak performans optimizasyon s\u00fcreci burada bitmez. Mevcut indekslerin d\u00fczenli olarak izlenmesi, optimize edilmesi ve bak\u0131m\u0131, veritaban\u0131 performans\u0131n\u0131n uzun vadede s\u00fcrd\u00fcr\u00fclebilirli\u011fi i\u00e7in kritik \u00f6neme sahiptir. Zamanla, veritaban\u0131n\u0131zdaki veri desenleri, sorgu y\u00fckleri ve sistem gereksinimleri de\u011fi\u015febilir. Bu de\u011fi\u015fiklikler, daha \u00f6nce m\u00fckemmel \u00e7al\u0131\u015fan indeksleri ya gereksiz hale getirebilir ya da daha az etkili k\u0131labilir. Bu nedenle, indeksleme stratejinizin ya\u015fayan bir s\u00fcre\u00e7 olmas\u0131 ve s\u00fcrekli adapte edilmesi gerekir.<\/p>\n \u0130lk olarak, kullan\u0131lmayan veya \"\u00f6l\u00fc\" indeksleri tespit etmek ve kald\u0131rmak b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Her bir indeks, disk alan\u0131 t\u00fcketir ve veri de\u011fi\u015fikliklerinde ek y\u00fck olu\u015fturur. Veritaban\u0131 sistemleri (\u00f6rne\u011fin SQL Server'da \u0130kinci olarak, indekslerin par\u00e7alanma (fragmentation) durumu izlenmelidir. Veri ekleme, g\u00fcncelleme ve silme i\u015flemleri s\u0131ras\u0131nda indekslerin fiziksel yap\u0131s\u0131 d\u00fczensiz hale gelebilir. Par\u00e7alanma, indeksin disk \u00fczerindeki sayfalar\u0131n\u0131n mant\u0131ksal s\u0131ras\u0131n\u0131n fiziksel s\u0131ras\u0131ndan farkl\u0131 olmas\u0131 durumudur. Bu durum, veri okuma i\u015flemlerinde disk I\/O maliyetini art\u0131rarak performans\u0131 d\u00fc\u015f\u00fcrebilir. \u0130ndeks par\u00e7alanmas\u0131n\u0131 gidermek i\u00e7in indeks yeniden olu\u015fturma (rebuild) veya yeniden d\u00fczenleme (reorganize) i\u015flemleri yap\u0131l\u0131r. Yeniden olu\u015fturma, indeksi tamamen d\u00fc\u015f\u00fcr\u00fcp yeniden yarat\u0131rken, yeniden d\u00fczenleme indeksin fiziksel s\u0131ras\u0131n\u0131 d\u00fczeltmeye \u00e7al\u0131\u015f\u0131r ve genellikle daha az kaynak yo\u011fundur. SQL Server'da <\/code><\/p>\n \u00dc\u00e7\u00fcnc\u00fc olarak, veritaban\u0131 istatistiklerinin g\u00fcncel tutulmas\u0131 hayati \u00f6neme sahiptir. Veritaban\u0131 iyile\u015ftiricisi (optimizer), sorgu plan\u0131 olu\u015ftururken indeksler ve tablolar hakk\u0131ndaki istatistikleri kullan\u0131r. Bu istatistikler, belirli bir s\u00fctundaki veri da\u011f\u0131l\u0131m\u0131, benzersiz de\u011fer say\u0131s\u0131 gibi bilgileri i\u00e7erir. E\u011fer istatistikler g\u00fcncel de\u011filse, iyile\u015ftirici yanl\u0131\u015f tahminlerde bulunabilir ve optimal olmayan bir sorgu plan\u0131 se\u00e7erek performans d\u00fc\u015f\u00fc\u015f\u00fcne neden olabilir. \u00c7o\u011fu veritaban\u0131 sistemi istatistikleri otomatik olarak g\u00fcncellese de, b\u00fcy\u00fck veri de\u011fi\u015fikliklerinden sonra veya kritik tablolar i\u00e7in manuel olarak <\/code><\/p>\n Son olarak, veritaban\u0131 sistemleri genellikle indeksleme \u00f6nerileri sunan ara\u00e7lar veya \u00f6zellikler i\u00e7erir. \u00d6rne\u011fin, SQL Server'\u0131n Missing Index DMVs'si (Dinamik Y\u00f6netim G\u00f6r\u00fcn\u00fcmleri), iyile\u015ftiricinin bir sorgu i\u00e7in indeks arad\u0131\u011f\u0131n\u0131 ancak bulamad\u0131\u011f\u0131n\u0131 ve hangi indeksi \u00f6nerdi\u011fini g\u00f6sterir. Bu t\u00fcr \u00f6nerileri incelemek ve dikkatli bir \u015fekilde uygulamak, yeni performans f\u0131rsatlar\u0131 yakalaman\u0131za yard\u0131mc\u0131 olabilir. Ancak bu \u00f6nerileri k\u00f6r\u00fc k\u00f6r\u00fcne uygulamak yerine, kendi sorgu desenleriniz ve i\u015f y\u00fck\u00fcn\u00fczle birle\u015ftirerek de\u011ferlendirmeniz \u00f6nemlidir. S\u00fcrekli izleme ve proaktif bak\u0131m, indekslerin veritaban\u0131 performans\u0131na olumlu katk\u0131da bulunmas\u0131n\u0131 sa\u011flaman\u0131n anahtar\u0131d\u0131r.<\/p>\n Bir finans kurulu\u015fu, g\u00fcnl\u00fck milyonlarca i\u015flemin kaydedildi\u011fi b\u00fcy\u00fck bir i\u015flem veritaban\u0131 kullan\u0131yor. Raporlama sistemi, bu veriler \u00fczerinde karma\u015f\u0131k ve uzun s\u00fcreli sorgular \u00e7al\u0131\u015ft\u0131r\u0131yor. Ba\u015flang\u0131\u00e7ta bir\u00e7ok indeks olu\u015fturulmu\u015ftu, ancak zamanla performans d\u00fc\u015fmeye ba\u015flad\u0131. Yap\u0131lan incelemede, baz\u0131 indekslerin son bir y\u0131l i\u00e7inde hi\u00e7 kullan\u0131lmad\u0131\u011f\u0131 tespit edildi. Bu \u00f6l\u00fc indeksler kald\u0131r\u0131ld\u0131. Ard\u0131ndan, en s\u0131k kullan\u0131lan tablolar \u00fczerindeki kritik indeksler i\u00e7in haftal\u0131k G\u00fcn\u00fcm\u00fcz dijital d\u00fcnyas\u0131nda, kullan\u0131c\u0131lar\u0131n \u00e7o\u011fu mobil cihazlar \u00fczerinden internete eri\u015fiyor. Bu durum, mobil uygulamalar\u0131n ve responsive (duyarl\u0131) web sitelerinin performans\u0131n\u0131 her zamankinden daha kritik hale getiriyor. Bir\u00e7ok ki\u015fi, performans sorunlar\u0131n\u0131 sadece \u00f6n y\u00fcz (front-end) ile ili\u015fkilendirse de, arka plandaki (back-end) veritaban\u0131 performans\u0131, genel kullan\u0131c\u0131 deneyimini do\u011frudan etkileyen en \u00f6nemli fakt\u00f6rlerden biridir. \u0130\u015fte burada veritaban\u0131 indekslemesinin \u00f6nemi bir kez daha ortaya \u00e7\u0131k\u0131yor.<\/p>\n H\u0131zl\u0131 ve optimize edilmi\u015f veritaban\u0131 sorgular\u0131, mobil uygulamalar\u0131n ve responsive web sitelerinin kullan\u0131c\u0131ya daha h\u0131zl\u0131 veri sunmas\u0131n\u0131 sa\u011flar. D\u00fc\u015f\u00fcn\u00fcn ki bir mobil uygulamada bir \u00fcr\u00fcn listesini veya bir kullan\u0131c\u0131 profilini g\u00f6r\u00fcnt\u00fcl\u00fcyorsunuz. E\u011fer bu veriyi \u00e7eken arka plan sorgular\u0131 saniyelere yay\u0131lan gecikmelerle \u00e7al\u0131\u015f\u0131yorsa, uygulaman\u0131n y\u00fcklenme s\u00fcresi uzar ve kullan\u0131c\u0131 hayal k\u0131r\u0131kl\u0131\u011f\u0131na u\u011frar. Mobil kullan\u0131c\u0131lar, genellikle masa\u00fcst\u00fc kullan\u0131c\u0131lar\u0131ndan daha az sab\u0131rl\u0131d\u0131r ve gecikmeler, uygulaman\u0131n terk edilmesine veya web sitesinin kapat\u0131lmas\u0131na neden olabilir. Veritaban\u0131 indeksleme, bu sorgular\u0131n milisaniyeler i\u00e7inde tamamlanmas\u0131n\u0131 sa\u011flayarak, mobil uygulaman\u0131n veya web sitesinin ak\u0131c\u0131 ve h\u0131zl\u0131 hissettirmesine do\u011frudan katk\u0131da bulunur.<\/p>\n Responsive tasar\u0131m, farkl\u0131 ekran boyutlar\u0131na ve cihazlara uyum sa\u011flayan bir kullan\u0131c\u0131 aray\u00fcz\u00fc olu\u015fturmay\u0131 hedefler. Ancak responsive bir site ne kadar iyi tasarlanm\u0131\u015f olursa olsun, veritaban\u0131ndan veri \u00e7ekme s\u00fcresi yava\u015fsa, bu tasar\u0131m\u0131n sundu\u011fu h\u0131z ve ak\u0131c\u0131l\u0131k avantajlar\u0131 kaybolur. \u00d6zellikle yava\u015f mobil a\u011f ba\u011flant\u0131lar\u0131nda, sunucudan gelen her ek milisaniye gecikme, kullan\u0131c\u0131 deneyimini daha da k\u00f6t\u00fcle\u015ftirebilir. \u0130ndeksler sayesinde, veritaban\u0131 sunucusu gerekli veriyi \u00e7ok daha az i\u015flemle ve daha h\u0131zl\u0131 bir \u015fekilde geri d\u00f6nd\u00fcr\u00fcr. Bu, mobil cihazlar\u0131n s\u0131n\u0131rl\u0131 i\u015flem g\u00fcc\u00fc ve bellek kapasitesi d\u00fc\u015f\u00fcn\u00fcld\u00fc\u011f\u00fcnde, kullan\u0131c\u0131 aray\u00fcz\u00fcn\u00fcn daha h\u0131zl\u0131 render edilmesi ve genel olarak daha p\u00fcr\u00fczs\u00fcz bir deneyim sunulmas\u0131 anlam\u0131na gelir. Yani, \u00f6n y\u00fczdeki m\u00fckemmel responsive tasar\u0131m, arka plandaki g\u00fc\u00e7l\u00fc ve optimize edilmi\u015f bir veritaban\u0131 altyap\u0131s\u0131yla desteklendi\u011finde ger\u00e7ek de\u011ferini bulur.<\/p>\n Mobil uyumlu HTML ve CSS kullan\u0131m\u0131, \u00f6n y\u00fcz performans\u0131n\u0131 art\u0131r\u0131rken, indeksleme de arka plandaki performans\u0131 art\u0131r\u0131r. Birbirini tamamlayan bu iki yakla\u015f\u0131m, son kullan\u0131c\u0131n\u0131n sorunsuz bir deneyim ya\u015famas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, a\u015fa\u011f\u0131daki gibi bir CSS media query yap\u0131s\u0131, sitenizin farkl\u0131 ekran boyutlar\u0131nda nas\u0131l g\u00f6r\u00fcnece\u011fini ayarlarken, arka planda da indeksler sayesinde h\u0131zl\u0131 veri ak\u0131\u015f\u0131 devam eder:<\/p>\nWHERE<\/code> c\u00fcmlesinde, ORDER BY<\/code> veya GROUP BY<\/code> ifadelerinde kullan\u0131lan di\u011fer s\u00fctunlar da indekslenerek sorgu performans\u0131 ciddi \u015fekilde art\u0131r\u0131labilir. Do\u011fru yerde do\u011fru indeksin bulunmas\u0131, sunucu kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131na yol a\u00e7ar, \u00e7\u00fcnk\u00fc daha az i\u015flem g\u00fcc\u00fc ve bellek t\u00fcketilir. Bu da genel sistem yan\u0131t s\u00fcresini iyile\u015ftirerek kullan\u0131c\u0131 deneyimini do\u011frudan etkiler. Veritaban\u0131 optimizasyonu s\u00f6z konusu oldu\u011funda, indeksleme genellikle ilk ba\u015fvurulan ve en etkili y\u00f6ntemlerden biridir. Ancak, her iyile\u015ftirme gibi, indekslemenin de kendi zorluklar\u0131 ve tuzaklar\u0131 vard\u0131r. Gere\u011finden fazla indeks veya yanl\u0131\u015f olu\u015fturulmu\u015f indeksler, performans\u0131 art\u0131rmak yerine d\u00fc\u015f\u00fcrebilir. Bu nedenle, indeksleme kararlar\u0131 dikkatle al\u0131nmal\u0131 ve s\u00fcrekli olarak g\u00f6zden ge\u00e7irilmelidir. \u0130ndekslerin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve hangi durumlarda ne t\u00fcr indekslerin faydal\u0131 olabilece\u011fini anlamak, veritaban\u0131 y\u00f6neticileri ve geli\u015ftiriciler i\u00e7in kritik bir beceridir.<\/p>\n\u0130ndeksleme: Bir \u00c7\u00f6z\u00fcm m\u00fc, Yeni Bir Problem mi?<\/h2>\n
INSERT<\/code> i\u015flemi, yeni bir kayd\u0131 tabloya eklerken ayn\u0131 zamanda bu tablo \u00fczerindeki her bir indeksin de g\u00fcncellenmesini gerektirir. Bu durum, \u00f6zellikle y\u00fcksek yazma yo\u011funlu\u011funa sahip sistemlerde, yani s\u00fcrekli veri eklenen, g\u00fcncellenen veya silinen veritabanlar\u0131nda ciddi bir performans darbo\u011faz\u0131 yaratabilir. Dizin g\u00fcncellemeleri, ek disk I\/O operasyonlar\u0131 ve CPU zaman\u0131 anlam\u0131na gelir. Dolay\u0131s\u0131yla, bir sorgunun okunmas\u0131 h\u0131zlan\u0131rken, verinin yaz\u0131lma s\u00fcresi uzar. Bu durum, genel sistem yan\u0131t s\u00fcresini d\u00fc\u015f\u00fcrebilir ve \u00f6zellikle toplu veri y\u00fckleme (bulk insert) gibi i\u015flemlerde beklenmedik yava\u015flamalara neden olabilir. \u00d6rne\u011fin, bir CRM sisteminde her yeni m\u00fc\u015fteri kayd\u0131n\u0131n veya her sat\u0131\u015f i\u015flemine ait verinin eklendi\u011fi bir tabloda \u00e7ok say\u0131da indeks bulunmas\u0131, veri yazma i\u015flemlerini yava\u015flatarak genel sistem verimlili\u011fini olumsuz etkileyebilir.<\/p>\nDo\u011fru \u0130ndeksi Se\u00e7mek ve Olu\u015fturmak Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
WHERE<\/code> c\u00fcmlesinde e\u015fitlik (=<\/code>) veya aral\u0131k (><\/code>, <<\/code>, BETWEEN<\/code>) ko\u015fullar\u0131yla kullan\u0131lan s\u00fctunlar, JOIN<\/code> i\u015flemlerinde kullan\u0131lan s\u00fctunlar ve ORDER BY<\/code> veya GROUP BY<\/code> ile s\u0131ralanan ya da gruplanan s\u00fctunlar indeksleme i\u00e7in iyi adaylard\u0131r.<\/p>\nEXPLAIN PLAN<\/code>, PostgreSQL'de EXPLAIN ANALYZE<\/code>, MySQL'de ise sadece EXPLAIN<\/code> komutu bu i\u015flevi g\u00f6r\u00fcr. Bu komutlar, bir sorgunun nas\u0131l y\u00fcr\u00fct\u00fclece\u011fini, hangi indeksleri kullanaca\u011f\u0131n\u0131 (veya kullanmayaca\u011f\u0131n\u0131), ka\u00e7 sat\u0131r\u0131 tarad\u0131\u011f\u0131n\u0131 ve ne kadar maliyetli oldu\u011funu ad\u0131m ad\u0131m g\u00f6sterir. Bu bilgiler, bir sorgunun neden yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlaman\u0131za ve do\u011fru indeksi olu\u015fturmak i\u00e7in yol haritas\u0131 \u00e7izmenize yard\u0131mc\u0131 olur.<\/p>\n\nSELECT urun_adi, fiyat, stok_miktari\nFROM urunler\nWHERE kategori_id = 5 AND fiyat BETWEEN 100 AND 500\nORDER BY fiyat DESC;\n <\/pre>\nEXPLAIN<\/code> \u00e7\u0131kt\u0131s\u0131na bakt\u0131\u011f\u0131m\u0131zda, kategori_id<\/code> ve fiyat<\/code> s\u00fctunlar\u0131 \u00fczerinde yo\u011fun bir tarama yap\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6rebiliriz. Bu durumda, bu iki s\u00fctunu i\u00e7eren kompozit (bile\u015fik) bir indeks olu\u015fturmak faydal\u0131 olacakt\u0131r. Kompozit indeks olu\u015ftururken s\u00fctunlar\u0131n s\u0131ras\u0131 \u00e7ok \u00f6nemlidir. Sorgular\u0131n\u0131zda e\u015fitlik ko\u015fulu ile filtreledi\u011finiz s\u00fctunlar\u0131 (\u00f6rne\u011fin kategori_id<\/code>) genellikle indeksin ba\u015f\u0131na koymal\u0131s\u0131n\u0131z, ard\u0131ndan aral\u0131k sorgular\u0131nda veya s\u0131ralamada kulland\u0131\u011f\u0131n\u0131z s\u00fctunlar\u0131 (\u00f6rne\u011fin fiyat<\/code>) getirmelisiniz. Bu senaryoda a\u015fa\u011f\u0131daki gibi bir indeks d\u00fc\u015f\u00fcn\u00fclebilir:<\/p>\n\nCREATE INDEX idx_urunler_kategori_fiyat ON urunler (kategori_id, fiyat);\n <\/pre>\nkategori_id = 5<\/code> ko\u015fulunu h\u0131zla filtreleyecek ve ard\u0131ndan o kategori i\u00e7indeki \u00fcr\u00fcnleri fiyat<\/code>a g\u00f6re s\u0131ral\u0131 bir \u015fekilde bulmay\u0131 kolayla\u015ft\u0131racakt\u0131r. ORDER BY fiyat DESC<\/code> de bu indeksten faydalanabilir. E\u011fer sorguda sadece kategori_id<\/code> kullan\u0131l\u0131yorsa, indeksin kategori_id<\/code> k\u0131sm\u0131 yine etkili olacakt\u0131r. Ancak sadece fiyat<\/code> kullan\u0131l\u0131yorsa, indeksin fiyat<\/code> k\u0131sm\u0131 tek ba\u015f\u0131na bir performans sa\u011flamayabilir, \u00e7\u00fcnk\u00fc indeks kategori_id<\/code> ile ba\u015flar.<\/p>\nVaka Analizi: E-ticaret Sitesi \u00dcr\u00fcn Arama<\/h3>\n
urunler<\/code> tablosunda (10 milyon kay\u0131t) kategori_id<\/code>, marka_id<\/code>, fiyat<\/code>, stok_miktari<\/code> gibi s\u00fctunlar bulunuyor. Kullan\u0131c\u0131lar genellikle belirli bir kategoride, belirli bir markan\u0131n \u00fcr\u00fcnlerini fiyat aral\u0131\u011f\u0131na g\u00f6re ar\u0131yor ve sonu\u00e7lar\u0131 fiyata g\u00f6re s\u0131ral\u0131yor. \u0130lk ba\u015fta sadece kategori_id<\/code> \u00fczerinde basit bir indeks vard\u0131. Ancak bu, marka_id<\/code> ve fiyat<\/code> filtreleri ile birle\u015fti\u011finde EXPLAIN<\/code> \u00e7\u0131kt\u0131s\u0131 hala tam indeks taramas\u0131 veya k\u0131smi tablo taramas\u0131 g\u00f6steriyordu. Ard\u0131ndan a\u015fa\u011f\u0131daki sorgu i\u00e7in bir kompozit indeks \u00f6nerildi:<\/p>\n\nSELECT urun_adi, fiyat, stok_miktari\nFROM urunler\nWHERE kategori_id = 10 AND marka_id = 5 AND fiyat BETWEEN 50 AND 200\nORDER BY fiyat ASC;\n <\/pre>\n(kategori_id, marka_id, fiyat)<\/code> \u015feklinde olmal\u0131yd\u0131. Bu indeks olu\u015fturulduktan sonra, sorgunun \u00e7al\u0131\u015fma s\u00fcresi 4 saniyeden 50 milisaniyeye d\u00fc\u015ft\u00fc. \u0130ndeksin kategori_id<\/code> ve marka_id<\/code> k\u0131s\u0131mlar\u0131, h\u0131zl\u0131 filtreleme sa\u011flarken, fiyat<\/code> k\u0131sm\u0131 da BETWEEN<\/code> sorgusunu ve ORDER BY<\/code> i\u015flemini optimize etti. Bu, do\u011fru kompozit indeksin kritik sorgular \u00fczerindeki d\u00f6n\u00fc\u015ft\u00fcr\u00fcc\u00fc etkisini a\u00e7\u0131k\u00e7a g\u00f6steren bir \u00f6rnektir. Do\u011fru indeksleme, sadece sorgular\u0131 h\u0131zland\u0131rmakla kalmaz, ayn\u0131 zamanda sunucu kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131na da olanak tan\u0131r.<\/p>\nMevcut \u0130ndeksleri Optimizasyon ve Bak\u0131m Stratejileri<\/h2>\n
sys.dm_db_index_usage_stats<\/code>, PostgreSQL'de pg_stat_user_indexes<\/code>), indekslerin ne kadar s\u0131k kullan\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6steren istatistikler sa\u011flar. Bu istatistikleri d\u00fczenli olarak kontrol ederek hi\u00e7 kullan\u0131lmayan veya \u00e7ok nadiren kullan\u0131lan indeksleri belirleyebilirsiniz. Bu indeksleri kald\u0131rmak, hem disk alan\u0131ndan tasarruf sa\u011flar hem de INSERT<\/code>, UPDATE<\/code>, DELETE<\/code> i\u015flemlerinin performans\u0131n\u0131 art\u0131r\u0131r. \u00d6rne\u011fin, bir zamanlar yo\u011fun olarak kullan\u0131lan bir raporlama sorgusu art\u0131k \u00e7al\u0131\u015fm\u0131yorsa ve bu sorguya \u00f6zel bir indeks varsa, bu indeksin kald\u0131r\u0131lmas\u0131 genel sistem performans\u0131na olumlu etki yapacakt\u0131r.<\/p>\nALTER INDEX ... REBUILD<\/code> veya ALTER INDEX ... REORGANIZE<\/code>, PostgreSQL'de REINDEX TABLE<\/code> veya REINDEX INDEX<\/code> komutlar\u0131 bu i\u015flemler i\u00e7in kullan\u0131l\u0131r.<\/p>\n\n-- SQL Server'da indeks yeniden olu\u015fturma\nALTER INDEX IX_Urunler_KategoriFiyat ON Urunler REBUILD;\n\n-- PostgreSQL'de belirli bir indeksi yeniden olu\u015fturma\nREINDEX INDEX idx_urunler_kategori_fiyat;\n <\/pre>\nANALYZE TABLE<\/code> (MySQL, PostgreSQL) veya UPDATE STATISTICS<\/code> (SQL Server) komutlar\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rmak faydal\u0131 olabilir.<\/p>\n\n-- MySQL veya PostgreSQL'de tablo istatistiklerini g\u00fcncelleme\nANALYZE TABLE urunler;\n\n-- SQL Server'da tablo istatistiklerini g\u00fcncelleme\nUPDATE STATISTICS urunler;\n <\/pre>\nVaka Analizi: B\u00fcy\u00fck Bir Raporlama Sisteminde \u0130ndeks Bak\u0131m\u0131<\/h3>\n
EXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131lar\u0131, baz\u0131 sorgular\u0131n indeksleri hi\u00e7 kullanmad\u0131\u011f\u0131n\u0131, baz\u0131lar\u0131n\u0131n ise \u00e7ok yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6steriyordu. Sorun, indekslerin a\u015f\u0131r\u0131 par\u00e7alanmas\u0131 ve eski istatistiklerdi.<\/p>\nREBUILD<\/code> operasyonlar\u0131 planland\u0131. Ayr\u0131ca, i\u015flem tablolar\u0131ndaki istatistikler, her gece toplu veri y\u00fcklemesinden sonra manuel olarak ANALYZE TABLE<\/code> komutlar\u0131 ile g\u00fcncellendi. Bu m\u00fcdahaleler sonucunda, raporlama sorgular\u0131n\u0131n ortalama \u00e7al\u0131\u015fma s\u00fcresi %60 oran\u0131nda azald\u0131. \u0130ndeks bak\u0131m\u0131 ve optimizasyonunun, karma\u015f\u0131k ve yo\u011fun sistemlerde ne kadar hayati oldu\u011funu g\u00f6steren g\u00fc\u00e7l\u00fc bir \u00f6rnektir.<\/p>\nMobil Uygulamalar ve Responsive Tasar\u0131mda \u0130ndekslemenin Rol\u00fc<\/h2>\n
\n