<\/span><\/h3>\n\n\n\nVeri taban\u0131 optimizasyonu, bir veritaban\u0131 y\u00f6netim sisteminin (DBMS) istenen verilere en k\u0131sa s\u00fcrede, en az sunucu kayna\u011f\u0131 (CPU, Bellek, Disk I\/O) harcayarak ula\u015fmas\u0131n\u0131 sa\u011flamak amac\u0131yla yap\u0131lan yap\u0131sal ve kodsal iyile\u015ftirmelerin b\u00fct\u00fcn\u00fcd\u00fcr.<\/p>\n\n\n\n
Dinamik bir web sitesinde bir kullan\u0131c\u0131 sayfay\u0131 her yeniledi\u011finde, arka planda veri taban\u0131na onlarca soru (sorgu\/query) sorulur. E\u011fer bu sorgular verimsiz yaz\u0131lm\u0131\u015fsa, veri taban\u0131 motoru istenen cevab\u0131 bulmak i\u00e7in milyonlarca sat\u0131r\u0131 ba\u015ftan a\u015fa\u011f\u0131 okumak zorunda kal\u0131r. Buna Full Table Scan (Tam Tablo Taramas\u0131)<\/strong> denir ve sistem performans\u0131n\u0131n en b\u00fcy\u00fck d\u00fc\u015fman\u0131d\u0131r. Optimizasyonun temel amac\u0131, veri taban\u0131 motoruna arad\u0131\u011f\u0131 verinin nerede oldu\u011funu en kestirme yoldan tarif etmektir.<\/p>\n\n\n\n<\/span>Yava\u015f \u00c7al\u0131\u015fan Sorgular\u0131 H\u0131zland\u0131rman\u0131n Profesyonel Teknikleri<\/span><\/h3>\n\n\n\nBir veri taban\u0131n\u0131n performans\u0131n\u0131 art\u0131rmak i\u00e7in sadece kodlar\u0131 de\u011fi\u015ftirmek yetmez; verinin nas\u0131l sakland\u0131\u011f\u0131n\u0131 ve nas\u0131l \u00e7a\u011fr\u0131ld\u0131\u011f\u0131n\u0131 stratejik olarak yeniden kurgulamak gerekir. \u0130\u015fte veri taban\u0131 darbo\u011fazlar\u0131n\u0131 ortadan kald\u0131racak en etkili teknikler:<\/p>\n\n\n\n
<\/span>1. \u0130ndeksleme (Indexing) G\u00fcc\u00fcn\u00fc Do\u011fru Kullanmak<\/span><\/h4>\n\n\n\n\u0130ndeksler, veri taban\u0131 optimizasyonunun en temel ve en g\u00fc\u00e7l\u00fc silah\u0131d\u0131r. Bir veri taban\u0131 indeksini, kal\u0131n bir ansiklopedinin sonundaki “i\u00e7indekiler” veya “dizin” b\u00f6l\u00fcm\u00fcne benzetebiliriz. Ansiklopedide belirli bir kelimeyi bulmak i\u00e7in binlerce sayfay\u0131 tek tek okumak yerine dizine bakar, kelimenin ge\u00e7ti\u011fi sayfa numaras\u0131n\u0131 bulur ve do\u011frudan o sayfaya gidersiniz.<\/p>\n\n\n\n
\u00d6rne\u011fin, sistem y\u00f6neticisi Volkan<\/strong>, e-ticaret sitesinin veri taban\u0131nda yer alan musteriler<\/code> tablosundan belirli bir e-posta adresini aramak istemektedir. Tabloda 5 milyon kay\u0131t vard\u0131r. E\u011fer email<\/code> s\u00fctununda bir indeks yoksa, veri taban\u0131 motoru aranan adresi bulana kadar 5 milyon kayd\u0131 s\u0131rayla okur. Ancak email<\/code> s\u00fctununa bir indeks eklendi\u011finde (genellikle B-Tree algoritmas\u0131 kullan\u0131l\u0131r), arama i\u015flemi saniyelerden milisaniyelere d\u00fc\u015fer.<\/p>\n\n\n\n\u0130ndeksleme Yaparken Dikkat Edilmesi Gerekenler:<\/strong><\/p>\n\n\n\n\nA\u015f\u0131r\u0131 \u0130ndekslemeden Ka\u00e7\u0131n\u0131n:<\/strong> Tablonuzdaki her s\u00fctuna indeks eklemek b\u00fcy\u00fck bir hatad\u0131r. \u0130ndeksler SELECT<\/code> (okuma) i\u015flemlerini inan\u0131lmaz h\u0131zland\u0131r\u0131rken; INSERT<\/code>, UPDATE<\/code> ve DELETE<\/code> (yazma\/g\u00fcncelleme) i\u015flemlerini yava\u015flat\u0131r. \u00c7\u00fcnk\u00fc her yeni kay\u0131t eklendi\u011finde, veri taban\u0131 sadece tabloyu de\u011fil, arka plandaki indeks a\u011fac\u0131n\u0131 da g\u00fcncellemek zorundad\u0131r.<\/li>\n\n\n\nBile\u015fik \u0130ndeksler (Composite Indexes):<\/strong> E\u011fer sorgular\u0131n\u0131zda birden fazla s\u00fctunu ayn\u0131 anda filtreliyorsan\u0131z (\u00d6rn: WHERE kategori_id = 5 AND durum = 'aktif'<\/code>), bu iki s\u00fctunu kapsayan tek bir bile\u015fik indeks olu\u015fturmak, ayr\u0131 ayr\u0131 indeks olu\u015fturmaktan \u00e7ok daha performansl\u0131d\u0131r.<\/li>\n<\/ul>\n\n\n\n<\/span>2. EXPLAIN Komutu ile Sorgu Anatomisini Analiz Etmek<\/span><\/h4>\n\n\n\nYava\u015f bir sorguyu h\u0131zland\u0131rman\u0131n ilk ad\u0131m\u0131, veri taban\u0131 motorunun o sorguyu arka planda nas\u0131l \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131 anlamakt\u0131r. SQL d\u00fcnyas\u0131nda bunu sa\u011flayan sihirli kelime EXPLAIN<\/strong> komutudur.<\/p>\n\n\n\nYazd\u0131\u011f\u0131n\u0131z yava\u015f bir SELECT<\/code> sorgusunun ba\u015f\u0131na EXPLAIN<\/code> kelimesini ekleyip \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, veri taban\u0131 size veriyi getirmek i\u00e7in izleyece\u011fi “Y\u00fcr\u00fctme Plan\u0131n\u0131” (Execution Plan) sunar. Bu rapor size \u015funlar\u0131 s\u00f6yler:<\/p>\n\n\n\n\nSorgu hangi indeksleri kullan\u0131yor? (veya indeksleri g\u00f6rmezden mi geliyor?)<\/li>\n\n\n\n Ka\u00e7 adet sat\u0131r taranacak?<\/li>\n\n\n\n Bellek \u00fczerinde ge\u00e7ici tablolar (Temporary Tables) olu\u015fturuluyor mu?<\/li>\n<\/ul>\n\n\n\nYaz\u0131l\u0131m geli\u015ftirici Selin<\/strong>, yazd\u0131\u011f\u0131 karma\u015f\u0131k bir raporlama sorgusunun \u00e7ok yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 fark etti\u011finde EXPLAIN<\/code> raporunu \u00e7eker. Raporda type: ALL<\/code> ifadesini g\u00f6rd\u00fc\u011f\u00fcnde, veri taban\u0131n\u0131n hi\u00e7bir indeksi kullanamad\u0131\u011f\u0131n\u0131 ve t\u00fcm tabloyu ba\u015ftan a\u015fa\u011f\u0131 tarad\u0131\u011f\u0131n\u0131 (Full Table Scan) anlar. Bu te\u015fhis, Selin’in hangi s\u00fctunlara indeks eklemesi gerekti\u011fini veya sorgudaki WHERE<\/code> \u015fartlar\u0131n\u0131 nas\u0131l de\u011fi\u015ftirmesi gerekti\u011fini do\u011frudan g\u00f6sterir.<\/p>\n\n\n\n<\/span>3. SELECT * Kullan\u0131m\u0131ndan \u015eiddetle Ka\u00e7\u0131nmak<\/span><\/h4>\n\n\n\nBir veri taban\u0131na yap\u0131labilecek en b\u00fcy\u00fck i\u015fkencelerden biri SELECT * FROM tablo_adi<\/code> komutunu al\u0131\u015fkanl\u0131k haline getirmektir. Y\u0131ld\u0131z (*) i\u015fareti, tablodaki “t\u00fcm s\u00fctunlar\u0131 getir” anlam\u0131na gelir.<\/p>\n\n\n\nDiyelim ki bir kullan\u0131c\u0131n\u0131n sadece ad\u0131n\u0131 ve soyad\u0131n\u0131 ekrana yazd\u0131racaks\u0131n\u0131z. Ancak tablonuzda kullan\u0131c\u0131n\u0131n biyografisi, profil foto\u011fraf\u0131n\u0131n base64 kodlar\u0131, son giri\u015f tarihleri gibi b\u00fcy\u00fck boyutlu 30 farkl\u0131 s\u00fctun var. SELECT *<\/code> dedi\u011finizde, ihtiyac\u0131n\u0131z olmayan gigabaytlarca veri diskten okunur (Disk I\/O maliyeti), a\u011f kablolar\u0131 \u00fczerinden uygulaman\u0131za ta\u015f\u0131n\u0131r (Network maliyeti) ve uygulaman\u0131z\u0131n RAM’ini (Bellek maliyeti) i\u015fgal eder.<\/p>\n\n\n\nBunun yerine her zaman sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 a\u00e7\u0131k\u00e7a belirterek<\/strong> sorgu yaz\u0131n: SELECT ad, soyad FROM kullanicilar WHERE id = 1;<\/code> Bu basit al\u0131\u015fkanl\u0131k, y\u00fcksek trafikli sistemlerde sunucu y\u00fck\u00fcn\u00fc yar\u0131 yar\u0131ya hafifletebilir.<\/p>\n\n\n\n<\/span>4. N+1 Sorgu Problemini ve \u00d6l\u00fcmc\u00fcl D\u00f6ng\u00fcleri \u00c7\u00f6zmek<\/span><\/h4>\n\n\n\n\u00d6zellikle Laravel, Hibernate veya Entity Framework gibi ORM (Object-Relational Mapping) ara\u00e7lar\u0131n\u0131 kullanan geli\u015ftiricilerin en s\u0131k d\u00fc\u015ft\u00fc\u011f\u00fc tuzak N+1 Problemidir.<\/strong><\/p>\n\n\n\nBlog sitesi sahibi Mert<\/strong>, ana sayfada son 10 makaleyi ve her makalenin yazar\u0131n\u0131n ad\u0131n\u0131 g\u00f6stermek istemektedir. K\u00f6t\u00fc kurgulanm\u0131\u015f bir kod yap\u0131s\u0131nda ORM arac\u0131 \u015fu mant\u0131kla \u00e7al\u0131\u015f\u0131r:<\/p>\n\n\n\n\n\u0130lk olarak makaleleri getirmek i\u00e7in 1 adet sorgu atar: SELECT * FROM makaleler LIMIT 10;<\/code><\/li>\n\n\n\nDaha sonra ekrana makaleleri basarken (d\u00f6ng\u00fc i\u00e7inde), her makalenin yazar\u0131n\u0131 bulmak i\u00e7in veri taban\u0131na tekrar<\/em> gider: SELECT * FROM yazarlar WHERE id = ?;<\/code><\/li>\n<\/ol>\n\n\n\nBu senaryoda 10 makale i\u00e7in veri taban\u0131na tam 11 adet<\/strong> (1 + 10) sorgu g\u00f6nderilmi\u015f olur. E\u011fer sayfada 100 makale listelenseydi, veri taban\u0131na 101 kez gidip gelinecekti. Veri taban\u0131 ile uygulama aras\u0131ndaki bu s\u00fcrekli “git-gel” trafi\u011fi sistemi inan\u0131lmaz derecede yava\u015flat\u0131r.<\/p>\n\n\n\n\u00c7\u00f6z\u00fcm:<\/strong> D\u00f6ng\u00fc i\u00e7erisinde asla sorgu at\u0131lmaz. Bunun yerine Eager Loading<\/strong> veya JOIN<\/strong> yap\u0131lar\u0131 kullan\u0131larak t\u00fcm veriler tek bir sorguda birle\u015ftirilip \u00e7ekilmelidir: SELECT m.*, y.ad AS yazar_adi FROM makaleler m JOIN yazarlar y ON m.yazar_id = y.id LIMIT 10;<\/code> B\u00f6ylece 101 sorgu yerine sadece 1 sorgu ile i\u015finizi bitirmi\u015f olursunuz.<\/p>\n\n\n\n<\/span>5. WHERE ve LIKE \u015eartlar\u0131nda Fonksiyon Kullan\u0131m\u0131n\u0131n Tehlikeleri<\/span><\/h4>\n\n\n\nBir indeksin \u00e7al\u0131\u015fabilmesi i\u00e7in aranan de\u011ferin net olmas\u0131 gerekir. E\u011fer WHERE<\/code> ko\u015fulunuzda s\u00fctunun \u00fczerine bir fonksiyon uygularsan\u0131z, veri taban\u0131 indeksleri kullanamaz ve tam tablo taramas\u0131 yapar.<\/p>\n\n\n\n\u00d6rne\u011fin; WHERE YEAR(kayit_tarihi) = 2026<\/code> \u015feklindeki bir sorgu veri taban\u0131n\u0131 fel\u00e7 edebilir. \u00c7\u00fcnk\u00fc veri taban\u0131 \u00f6nce milyonlarca sat\u0131rdaki tarihlerin y\u0131l\u0131n\u0131 hesaplamak (fonksiyonu \u00e7al\u0131\u015ft\u0131rmak), ard\u0131ndan 2026’ya e\u015fit olanlar\u0131 bulmak zorundad\u0131r; bu s\u0131rada indeks iptal olur. Do\u011fru kullan\u0131m:<\/strong> WHERE kayit_tarihi >= '2026-01-01' AND kayit_tarihi <= '2026-12-31'<\/code> \u015feklinde aral\u0131\u011f\u0131 net vererek indekslerin \u00e7al\u0131\u015fmas\u0131na izin vermektir.<\/p>\n\n\n\nAyn\u0131 \u015fekilde LIKE '%kelime%'<\/code> (ba\u015f\u0131nda ve sonunda y\u00fczde i\u015fareti olan) aramalar\u0131 indeksleri ge\u00e7ersiz k\u0131lar. Arama yaparken m\u00fcmk\u00fcnse sadece sa\u011fa do\u011fru (\u00d6rn: LIKE 'kelime%'<\/code>) joker karakter kullan\u0131lmal\u0131 veya devasa metin aramalar\u0131 i\u00e7in Elasticsearch gibi \u00f6zel tam metin arama (Full-Text Search) motorlar\u0131na ge\u00e7i\u015f yap\u0131lmal\u0131d\u0131r.<\/p>\n\n\n\n<\/span>6. \u00d6nbellekleme (Caching) Katman\u0131 Eklemek<\/span><\/h4>\n\n\n\nD\u00fcnyan\u0131n en optimize edilmi\u015f veri taban\u0131na sahip olsan\u0131z bile, saniyede binlerce kez ayn\u0131 sorguyu \u00e7al\u0131\u015ft\u0131rmak mant\u0131ks\u0131zd\u0131r. De\u011fi\u015fme s\u0131kl\u0131\u011f\u0131 d\u00fc\u015f\u00fck olan veriler (\u00d6rne\u011fin; e-ticaret sitesindeki kategoriler men\u00fcs\u00fc, pop\u00fcler blog yaz\u0131lar\u0131 veya sabit ayarlar) veri taban\u0131 yerine Redis<\/strong> veya Memcached<\/strong> gibi RAM \u00fczerinde \u00e7al\u0131\u015fan bellek i\u00e7i (In-Memory) veri depolar\u0131nda tutulmal\u0131d\u0131r.<\/p>\n\n\n\nKullan\u0131c\u0131 “Kategoriler” sayfas\u0131n\u0131 a\u00e7t\u0131\u011f\u0131nda, sistem \u00f6nce Redis’e bakar. Veri oradaysa milisaniyeler i\u00e7inde cevap d\u00f6ner, veri taban\u0131n\u0131n haberi bile olmaz. Bu strateji veri taban\u0131n\u0131z\u0131n \u00fczerindeki okuma y\u00fck\u00fcn\u00fc %80’lere varan oranda hafifleterek, veri taban\u0131n\u0131n sadece kritik yazma i\u015flemlerine (sipari\u015f olu\u015fturma, \u00f6deme alma) odaklanmas\u0131n\u0131 sa\u011flar.<\/p>\n\n\n\n
<\/span>7. De-Normalizasyon ve Tablo B\u00f6lme (Partitioning) Stratejileri<\/span><\/h4>\n\n\n\nAkademik olarak veri tabanlar\u0131 3NF (Normal Form) kurallar\u0131na g\u00f6re tasarlan\u0131r; yani veriler tekrar etmemesi i\u00e7in onlarca farkl\u0131 tabloya b\u00f6l\u00fcn\u00fcr. Ancak devasa sistemlerde 6-7 tabloyu JOIN<\/code> ile birle\u015ftirmek i\u015flemciyi kilitler. Mimar Asl\u0131<\/strong>, sistemin h\u0131zlanmas\u0131 i\u00e7in baz\u0131 durumlarda akademik kurallar\u0131 esneterek De-Normalizasyon<\/strong> (verileri bilerek tekrar ettirme veya \u00f6nceden hesaplanm\u0131\u015f s\u00fctunlar ekleme) y\u00f6ntemine ba\u015fvurur. \u00d6rne\u011fin, bir sipari\u015fteki toplam tutar\u0131 her seferinde alt \u00fcr\u00fcnleri toplayarak hesaplamak yerine, siparisler<\/code> tablosuna toplam_tutar<\/code> ad\u0131nda yeni bir s\u00fctun ekleyip de\u011feri orada haz\u0131r tutmak sorgu maliyetini s\u0131f\u0131ra indirir.<\/p>\n\n\n\n\u00c7ok b\u00fcy\u00fck verilerin (\u00f6rne\u011fin son 10 y\u0131l\u0131n fatura kay\u0131tlar\u0131) oldu\u011fu tablolarda ise Partitioning (B\u00f6l\u00fcmleme)<\/strong> yap\u0131larak tablo y\u0131llara veya aylara g\u00f6re fiziksel olarak k\u00fc\u00e7\u00fck par\u00e7alara ayr\u0131l\u0131r. B\u00f6ylece 2026 y\u0131l\u0131 faturalar\u0131 aran\u0131rken, veri taban\u0131 eski y\u0131llar\u0131n dosyalar\u0131na hi\u00e7 bakmadan \u00e7ok daha h\u0131zl\u0131 sonu\u00e7 \u00fcretir.<\/p>\n\n\n\n<\/span>Sonu\u00e7<\/span><\/h3>\n\n\n\nVeri taban\u0131 optimizasyonu, bir kez yap\u0131l\u0131p b\u0131rak\u0131lacak bir g\u00f6rev de\u011fil; uygulaman\u0131z b\u00fcy\u00fcd\u00fck\u00e7e s\u00fcrekli olarak izlenmesi (monitoring) ve iyile\u015ftirilmesi gereken canl\u0131 bir s\u00fcre\u00e7tir. Yava\u015flayan bir sistemde donan\u0131ma para harcamadan \u00f6nce sorgular\u0131n\u0131z\u0131 EXPLAIN<\/code> ile analiz edin, indekslerinizi stratejik olarak yerle\u015ftirin, SELECT *<\/code> tembelli\u011finden kurtulun ve ORM ara\u00e7lar\u0131n\u0131n olu\u015fturdu\u011fu gizli N+1<\/code> sorgular\u0131n\u0131 avlay\u0131n. Bu teknikleri disiplinli bir \u015fekilde uygulad\u0131\u011f\u0131n\u0131zda, sunucu kaynaklar\u0131n\u0131z\u0131n ne kadar rahatlad\u0131\u011f\u0131na ve uygulaman\u0131z\u0131n kullan\u0131c\u0131lara nas\u0131l \u0131\u015f\u0131k h\u0131z\u0131nda tepki verdi\u011fine \u015fahit olacaks\u0131n\u0131z.<\/p>\n","protected":false},"excerpt":{"rendered":"Dijital d\u00fcnyada saniyelerin, hatta milisaniyelerin bile devasa bir \u00f6nemi vard\u0131r.…<\/a><\/p>\n","protected":false},"author":6,"featured_media":23715,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-23714","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-genel"],"yoast_head":"\n