Veritabanlar\u0131, modern uygulamalar\u0131n temelidir. Ancak yava\u015f \u00e7al\u0131\u015fan SQL sorgular\u0131, kullan\u0131c\u0131 deneyimini olumsuz etkileyebilir, sistem kaynaklar\u0131n\u0131 israf edebilir ve hatta i\u015f s\u00fcre\u00e7lerini aksatabilir. Peki, SQL kodumuzu neden optimize etmeliyiz ve bu performans iyile\u015ftirmeleri ne kadar kritik? Gelin, bu sorular\u0131n cevaplar\u0131n\u0131 ke\u015ffedelim ve SQL kodunuzu daha verimli hale getirmenin temel ad\u0131mlar\u0131n\u0131 \u00f6\u011frenelim.<\/p>\n
Bir uygulaman\u0131n yava\u015f yan\u0131t vermesi veya bir raporun dakikalarca y\u00fcklenmesi, kullan\u0131c\u0131lar\u0131n sabr\u0131n\u0131 zorlayan yayg\u0131n sorunlard\u0131r. Bu durumlar, do\u011frudan k\u00f6t\u00fc yaz\u0131lm\u0131\u015f veya optimize edilmemi\u015f SQL sorgular\u0131ndan kaynaklanabilir. E-ticaret sitelerinde \u00fcr\u00fcn listelemenin yava\u015flamas\u0131 veya b\u00fcy\u00fck bir veri analizinin saatler s\u00fcrmesi, i\u015fletmeler i\u00e7in ciddi maliyetlere ve m\u00fc\u015fteri kayb\u0131na yol a\u00e7abilir. Bu nedenle, SQL kod optimizasyonu sadece teknik bir gereklilik de\u011fil, ayn\u0131 zamanda i\u015f s\u00fcreklili\u011fi ve rekabet avantaj\u0131 i\u00e7in vazge\u00e7ilmez bir stratejidir.<\/p>\n
Performans, yaln\u0131zca kullan\u0131c\u0131 bekleme s\u00fcresini azaltmakla kalmaz, ayn\u0131 zamanda sistem kaynaklar\u0131n\u0131n daha verimli kullan\u0131lmas\u0131n\u0131 sa\u011flar. Daha h\u0131zl\u0131 sorgular, daha az CPU, bellek ve I\/O (Giri\u015f\/\u00c7\u0131k\u0131\u015f) kayna\u011f\u0131 t\u00fcketir. Bu da sunucu maliyetlerinde d\u00fc\u015f\u00fc\u015fe ve ayn\u0131 donan\u0131m \u00fczerinde daha fazla kullan\u0131c\u0131ya hizmet verebilme kapasitesine yol a\u00e7ar. \u00d6l\u00e7eklenebilirlik a\u00e7\u0131s\u0131ndan bak\u0131ld\u0131\u011f\u0131nda, uygulaman\u0131z b\u00fcy\u00fcd\u00fck\u00e7e veri hacmi ve kullan\u0131c\u0131 say\u0131s\u0131 artacakt\u0131r. \u0130yi optimize edilmi\u015f SQL kodlar\u0131 olmadan, sisteminiz h\u0131zla performans darbo\u011fazlar\u0131na ula\u015facak ve \u00f6l\u00e7eklenmekte zorlanacakt\u0131r.<\/p>\n
Peki, “iyi” bir SQL sorgusu ne anlama gelir? \u0130stenen sonucu en az kaynakla ve en k\u0131sa s\u00fcrede d\u00f6nd\u00fcren sorgu “iyi” bir sorgudur. Veritaban\u0131 y\u00f6netim sistemlerinin (DBMS) sundu\u011fu sorgu y\u00fcr\u00fctme planlar\u0131n\u0131 (Execution Plan) incelemek, bir sorgunun performans\u0131n\u0131 anlaman\u0131n en etkili yollar\u0131ndan biridir. Bu planlar, veritaban\u0131 motorunun sorguyu nas\u0131l i\u015fledi\u011fini, hangi indeksleri kulland\u0131\u011f\u0131n\u0131, hangi tablolar\u0131 tarad\u0131\u011f\u0131n\u0131 ve ne kadar kaynak t\u00fcketti\u011fini g\u00f6sterir. Bu kritik bilgileri analiz ederek, darbo\u011fazlar\u0131 tespit edebilir ve optimizasyon i\u00e7in do\u011fru ad\u0131mlar\u0131 atabilirsiniz. Bu makalede, SQL kodunuzu ad\u0131m ad\u0131m nas\u0131l optimize edece\u011finizi, ger\u00e7ek d\u00fcnya senaryolar\u0131yla destekleyerek, en temel tekniklerden ileri d\u00fczey stratejilere kadar t\u00fcm detaylar\u0131yla \u00f6\u011freneceksiniz.<\/p>\n
SQL performans\u0131n\u0131 art\u0131rman\u0131n ilk ad\u0131m\u0131, sorgular\u0131 daha ak\u0131ll\u0131ca yazmakt\u0131r. Bir\u00e7ok performans sorunu, basit ama etkili tekniklerle \u00e7\u00f6z\u00fclebilir. Bu b\u00f6l\u00fcmde, s\u0131k\u00e7a yap\u0131lan hatalar\u0131 d\u00fczelterek ve en iyi uygulamalar\u0131 benimseyerek sorgular\u0131n\u0131z\u0131 nas\u0131l daha h\u0131zl\u0131 hale getirebilece\u011finizi inceleyece\u011fiz.<\/p>\n
SELECT *<\/code> Yerine Belirli S\u00fctunlar\u0131 Se\u00e7mek<\/h3>\nYeni ba\u015flayanlar\u0131n s\u0131k\u00e7a yapt\u0131\u011f\u0131 hatalardan biri, t\u00fcm s\u00fctunlar\u0131 se\u00e7mek i\u00e7in <\/p>\n
SELECT *<\/pre>\n<\/code> kullanmakt\u0131r. \u00d6zellikle geni\u015f tablolarda veya milyonlarca kay\u0131t i\u00e7eren tablolardan veri \u00e7ekerken bu durum performans\u0131 ciddi \u015fekilde etkileyebilir. \u0130htiyac\u0131n\u0131z olmayan s\u00fctunlar\u0131 \u00e7ekmek, hem a\u011f trafi\u011fini art\u0131r\u0131r hem de veritaban\u0131 sunucusunun gereksiz yere daha fazla veri okumas\u0131na neden olur.<\/p>\n
\n Uzman \u0130pucu: Her zaman sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 belirtin. Bu, hem sorgu performans\u0131n\u0131 art\u0131r\u0131r hem de uygulaman\u0131z\u0131n daha az bellek kullanmas\u0131n\u0131 sa\u011flar.\n <\/div>\n\u00d6rne\u011fin, bir kullan\u0131c\u0131 tablosundan sadece ad\u0131n\u0131 ve e-posta adresini almak istiyorsan\u0131z:<\/p>\n
\n -- K\u00f6t\u00fc Uygulama\n SELECT * FROM Kullanicilar WHERE Sehir = 'Ankara';\n\n -- \u0130yi Uygulama\n SELECT Ad, Soyad, Eposta FROM Kullanicilar WHERE Sehir = 'Ankara';\n <\/pre>\n<\/code><\/p>\n
WHERE<\/code> Ko\u015fullar\u0131n\u0131 Etkili Kullanmak<\/h3>\nWHERE<\/code> ko\u015fullar\u0131, sorgular\u0131n\u0131z\u0131n temel filtreleme mekanizmas\u0131d\u0131r. Bu ko\u015fullar\u0131 do\u011fru kullanmak, veritaban\u0131n\u0131n taranmas\u0131 gereken veri miktar\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r:<\/p>\n\n- Fonksiyon Kullan\u0131m\u0131ndan Ka\u00e7\u0131n\u0131n:<\/strong>
WHERE<\/code> ko\u015fulunda indekslenmi\u015f bir s\u00fctun \u00fczerinde fonksiyon kullanmak, veritaban\u0131n\u0131n indeksi kullanmas\u0131n\u0131 engelleyebilir (Full Table Scan'e neden olabilir). \u00d6rne\u011fin,\nWHERE YEAR(Tarih) = 2023<\/pre>\n<\/code> yerine <\/p>\n
WHERE Tarih BETWEEN '2023-01-01' AND '2023-12-31'<\/pre>\n<\/code> kullanmak daha etkilidir.<\/li>\n
LIKE<\/code> Operat\u00f6r\u00fc:<\/strong> M\u00fcmk\u00fcnse\nLIKE 'metin%'<\/pre>\n<\/code> \u015feklinde joker karakteri sona koyun. <\/p>\n
LIKE '%metin'<\/pre>\n<\/code> veya <\/p>\n
LIKE '%metin%'<\/pre>\n<\/code> kullanmak, indeksi devre d\u0131\u015f\u0131 b\u0131rakabilir.<\/li>\n<\/ul>\n
JOIN<\/code> T\u00fcrleri ve Do\u011fru Kullan\u0131m\u0131<\/h3>\nBirden fazla tablodan veri birle\u015ftirmek i\u00e7in JOIN<\/code> ifadelerini kullan\u0131r\u0131z. Do\u011fru JOIN<\/code> t\u00fcr\u00fcn\u00fc se\u00e7mek ve ON<\/code> ko\u015fulunu etkili bir \u015fekilde yazmak \u00e7ok \u00f6nemlidir:<\/p>\n\nINNER JOIN<\/code>:<\/strong> Sadece her iki tabloda da e\u015fle\u015fen kay\u0131tlar\u0131 getirir. En s\u0131k kullan\u0131lan ve genellikle en performansl\u0131 t\u00fcrd\u00fcr.<\/li>\nLEFT JOIN<\/code> \/ RIGHT JOIN<\/code>:<\/strong> Bir tablodaki t\u00fcm kay\u0131tlar\u0131 getirirken, di\u011fer tablodan sadece e\u015fle\u015fenleri getirir.<\/li>\nFULL OUTER JOIN<\/code>:<\/strong> Her iki tablodaki t\u00fcm kay\u0131tlar\u0131 getirir. Genellikle performans\u0131 en d\u00fc\u015f\u00fck olan\u0131d\u0131r.<\/li>\n<\/ul>\nON<\/code> ko\u015fulunda indekslenmi\u015f s\u00fctunlar\u0131 kullanmaya \u00f6zen g\u00f6sterin. Gereksiz birle\u015ftirmelerden ka\u00e7\u0131n\u0131n. Sadece ihtiyac\u0131n\u0131z olan tablolar\u0131 birle\u015ftirin.<\/p>\nDISTINCT<\/code> ve GROUP BY<\/code> Farklar\u0131<\/h3>\nTekil de\u011ferler elde etmek i\u00e7in her ikisi de kullan\u0131labilir, ancak \u00e7al\u0131\u015fma prensipleri ve performans etkileri farkl\u0131d\u0131r. DISTINCT<\/code>, se\u00e7ilen t\u00fcm s\u00fctunlar\u0131n kombinasyonunda benzersiz kay\u0131tlar\u0131 d\u00f6nd\u00fcr\u00fcrken, GROUP BY<\/code> belirtilen s\u00fctunlara g\u00f6re sat\u0131rlar\u0131 grupland\u0131r\u0131r ve genellikle toplama i\u015flemleri i\u00e7in kullan\u0131l\u0131r. Performans a\u00e7\u0131s\u0131ndan, sadece tekil de\u011ferlere ihtiyac\u0131n\u0131z varsa DISTINCT<\/code> genellikle daha basit bir y\u00fcr\u00fctme plan\u0131na sahip olabilir.<\/p>\nVaka Analizi: Basit SELECT<\/code> Optimizasyonu<\/h3>\nBir e-ticaret siteniz var ve \"Elektronik\" kategorisindeki \u00fcr\u00fcnleri \u00e7ekerken sayfan\u0131z yava\u015f y\u00fckl\u00fcyor. Orijinal sorgu \u015f\u00f6yle olabilir:<\/p>\n
\n -- Orijinal (Yava\u015f) Sorgu\n SELECT *\n FROM Urunler\n WHERE Kategori = 'Elektronik' AND StokAdedi > 0;\n <\/pre>\n<\/code><\/p>\n
Optimizasyon ad\u0131mlar\u0131:<\/p>\n
\n- Sadece ihtiyac\u0131n\u0131z olan s\u00fctunlar\u0131 se\u00e7in (\u00f6rne\u011fin, UrunAdi, Fiyat).<\/li>\n
Kategori<\/code> ve StokAdedi<\/code> s\u00fctunlar\u0131 \u00fczerinde indeks olu\u015fturun (ileride daha detayl\u0131 anlat\u0131lacak).<\/li>\n<\/ol>\n\n -- Optimize Edilmi\u015f Sorgu\n SELECT UrunAdi, Fiyat, Aciklama\n FROM Urunler\n WHERE Kategori = 'Elektronik' AND StokAdedi > 0;\n <\/pre>\n<\/code><\/p>\n
Bu basit de\u011fi\u015fiklikler, milyonlarca kay\u0131t i\u00e7eren tablolar i\u00e7in \u00f6nemli performans iyile\u015ftirmeleri sa\u011flayabilir.<\/p>\n
Indeksler: Veritaban\u0131 Performans\u0131n\u0131n Anahtar\u0131 Nas\u0131l Kullan\u0131l\u0131r?<\/h3>\n
Veritaban\u0131 optimizasyonunun en g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131ndan biri indekslerdir. Indeksler, veritaban\u0131 tablolar\u0131n\u0131zdaki belirli s\u00fctunlar \u00fczerinde h\u0131zl\u0131 arama ve s\u0131ralama i\u015flemleri yap\u0131lmas\u0131na olanak tan\u0131yan \u00f6zel arama tablolar\u0131d\u0131r. T\u0131pk\u0131 bir kitab\u0131n arkas\u0131ndaki dizin gibi, arad\u0131\u011f\u0131n\u0131z bilgiyi t\u00fcm kitab\u0131 okumak yerine do\u011frudan ilgili sayfaya y\u00f6nlendirerek bulman\u0131z\u0131 sa\u011flarlar. Indeksler olmadan, veritaban\u0131 her sorguda tablonun tamam\u0131n\u0131 sat\u0131r sat\u0131r taramak zorunda kal\u0131r ki bu da \"Full Table Scan\" olarak adland\u0131r\u0131l\u0131r ve genellikle olduk\u00e7a yava\u015ft\u0131r.<\/p>\n
Indeks Nedir ve Neden \u00d6nemlidir?<\/h4>\n
Bir indeks, tablodaki bir veya daha fazla s\u00fctunun de\u011ferlerini ve bu de\u011ferlerin depoland\u0131\u011f\u0131 fiziksel konumlar\u0131 i\u00e7eren s\u0131ral\u0131 bir veri yap\u0131s\u0131d\u0131r. En yayg\u0131n indeks t\u00fcr\u00fc B-Tree (B-A\u011fac\u0131) indeksidir. Veritaban\u0131 motoru, bir sorgu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131nda, e\u011fer uygun bir indeks varsa, do\u011frudan bu indeksi kullanarak ilgili verilere h\u0131zl\u0131ca eri\u015fir. Bu, \u00f6zellikle b\u00fcy\u00fck tablolarda milyonlarca sat\u0131r aras\u0131nda arama yaparken sorgu s\u00fcresini dramatik \u015fekilde k\u0131salt\u0131r.<\/p>\n
Ne Zaman Indekslemeli, Ne Zaman Ka\u00e7\u0131nmal\u0131?<\/h4>\n
Indeksler performans\u0131 art\u0131rsa da, her s\u00fctuna indeks eklemek her zaman iyi bir fikir de\u011fildir. Indekslerin de kendi maliyetleri vard\u0131r: depolama alan\u0131 kaplar ve INSERT<\/code>, UPDATE<\/code>, DELETE<\/code> i\u015flemleri s\u0131ras\u0131nda g\u00fcncellenmeleri gerekti\u011fi i\u00e7in yazma performans\u0131n\u0131 d\u00fc\u015f\u00fcrebilirler.<\/p>\nGenellikle indekslenmesi gereken durumlar:<\/p>\n
\nWHERE<\/code>, JOIN<\/code>, ORDER BY<\/code>, GROUP BY<\/code> ve DISTINCT<\/code> ko\u015fullar\u0131nda s\u0131k\u00e7a kullan\u0131lan s\u00fctunlar.<\/li>\n- Y\u00fcksek kardinaliteye sahip s\u00fctunlar (\u00e7ok say\u0131da farkl\u0131 de\u011fere sahip, \u00f6rne\u011fin T.C. Kimlik Numaras\u0131, E-posta Adresi).<\/li>\n
- Yabanc\u0131 anahtarlar (Foreign Keys).<\/li>\n<\/ul>\n
Ka\u00e7\u0131n\u0131lmas\u0131 gereken durumlar:<\/p>\n
\n- D\u00fc\u015f\u00fck kardinaliteye sahip s\u00fctunlar (\u00f6rne\u011fin, cinsiyet, boolean bayraklar\u0131).<\/li>\n
- \u00c7ok s\u0131k g\u00fcncellenen s\u00fctunlar.<\/li>\n<\/ul>\n
Clustered vs. Non-Clustered Indeksler<\/h4>\n
\u0130ki ana indeks t\u00fcr\u00fc vard\u0131r:<\/p>\n
\n- \n Clustered Indeks:<\/strong> Bir tabloda sadece bir tane olabilir. Veri sat\u0131rlar\u0131n\u0131n fiziksel depolama s\u0131ras\u0131n\u0131 belirler. Tablo verilerinin kendisi, indeksin anahtar s\u00fctunlar\u0131na g\u00f6re fiziksel olarak s\u0131ralan\u0131r. Birincil anahtarlar genellikle otomatik olarak clustered indeks olarak olu\u015fturulur.\n <\/li>\n
- \n Non-Clustered Indeks:<\/strong> Bir tabloda birden fazla olabilir. Tablonun fiziksel s\u0131ralamas\u0131n\u0131 de\u011fi\u015ftirmezler. Bunun yerine, indeks anahtar\u0131 ve verinin bulundu\u011fu konumun bir i\u015faret\u00e7isini i\u00e7erirler.\n <\/li>\n<\/ul>\n
Covering Indeksler<\/h4>\n
Covering indeks, bir sorgunun ihtiya\u00e7 duydu\u011fu t\u00fcm s\u00fctunlar\u0131 (SELECT<\/code>, WHERE<\/code>, JOIN<\/code> vb.) i\u00e7eren bir non-clustered indekstir. Bu sayede veritaban\u0131, sorguyu \u00e7al\u0131\u015ft\u0131rmak i\u00e7in tabloya geri d\u00f6nmek (lookup yapmak) zorunda kalmaz, t\u00fcm bilgiyi do\u011frudan indeksten okuyabilir. Bu, I\/O operasyonlar\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n\n -- Indeks olu\u015fturma \u00f6rne\u011fi\n CREATE INDEX IX_Urunler_KategoriFiyat\n ON Urunler (Kategori)\n INCLUDE (Fiyat); -- Fiyat s\u00fctunu indekse dahil edildi\n <\/pre>\n<\/code><\/p>\n
\n Uzman \u0130pucu: Indeksler, iki ucu keskin bir b\u0131\u00e7ak gibidir. Performans\u0131 art\u0131r\u0131rken, yazma i\u015flemlerini yava\u015flatabilir ve depolama alan\u0131 t\u00fcketebilirler. Indeks stratejinizi belirlerken, sorgu t\u00fcrlerinizi (okuma\/yazma oran\u0131) ve veri da\u011f\u0131l\u0131m\u0131n\u0131z\u0131 dikkatlice analiz edin.\n <\/div>\nKarma\u015f\u0131k Sorgular\u0131 Geli\u015ftirme: Alt Sorgular ve CTE'ler<\/h2>\n
Veritaban\u0131 i\u015flemlerinde bazen basit SELECT<\/code>, WHERE<\/code> ve JOIN<\/code> ifadeleri yeterli olmaz. Daha karma\u015f\u0131k veri manip\u00fclasyonlar\u0131 veya ad\u0131m ad\u0131m mant\u0131k gerektiren durumlarda alt sorgular (Subqueries) ve Ortak Tablo \u0130fadeleri (Common Table Expressions - CTE'ler) devreye girer. Bu b\u00f6l\u00fcmde, bu g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131 nas\u0131l etkili bir \u015fekilde kullanaca\u011f\u0131m\u0131z\u0131 ve SQL kodunuzu daha okunabilir ve performansl\u0131 hale getirece\u011fimizi \u00f6\u011frenece\u011fiz.<\/p>\nAlt Sorgular\u0131n Art\u0131lar\u0131 ve Eksileri<\/h3>\n
Alt sorgular, bir ana sorgu i\u00e7inde yer alan ba\u015fka bir sorgudur. Genellikle bir ko\u015ful i\u00e7inde (WHERE<\/code>), bir s\u00fctun olarak (SELECT<\/code> listesi) veya bir tablo kayna\u011f\u0131 olarak (FROM<\/code>) kullan\u0131l\u0131rlar. Belirli bir hesaplamay\u0131 veya filtrelemeyi ana sorgudan ba\u011f\u0131ms\u0131z olarak yap\u0131p sonucunu ana sorguya iletmek i\u00e7in harikad\u0131rlar.<\/p>\n\u00d6rnek bir alt sorgu:<\/p>\n
\n SELECT UrunAdi, Fiyat\n FROM Urunler\n WHERE KategoriID IN (SELECT KategoriID FROM Kategoriler WHERE KategoriAdi = 'Elektronik');\n <\/pre>\n<\/code><\/p>\n
Ancak alt sorgular\u0131n baz\u0131 dezavantajlar\u0131 da vard\u0131r: \u00f6zellikle ili\u015fkisel (correlated) alt sorgular, b\u00fcy\u00fck veri setlerinde ciddi performans sorunlar\u0131na yol a\u00e7abilir. Ayr\u0131ca, \u00e7ok say\u0131da i\u00e7 i\u00e7e ge\u00e7mi\u015f alt sorgu, kodun anla\u015f\u0131lmas\u0131n\u0131 ve hata ay\u0131klamas\u0131n\u0131 zorla\u015ft\u0131rabilir.<\/p>\n
Ortak Tablo \u0130fadeleri (CTE - Common Table Expressions) Nedir?<\/h3>\n
CTE'ler, modern RDBMS'ler taraf\u0131ndan desteklenen, sorgular\u0131n\u0131zda ge\u00e7ici, adland\u0131r\u0131lm\u0131\u015f sonu\u00e7 k\u00fcmeleri olu\u015fturman\u0131za olanak tan\u0131yan g\u00fc\u00e7l\u00fc bir \u00f6zelliktir. Bir CTE, bir kez tan\u0131mland\u0131ktan sonra bir SELECT<\/code>, INSERT<\/code>, UPDATE<\/code>, DELETE<\/code> veya ba\u015fka bir CTE i\u00e7inde referans al\u0131nabilir. CTE'ler, karma\u015f\u0131k sorgular\u0131 daha k\u00fc\u00e7\u00fck, daha y\u00f6netilebilir mant\u0131ksal par\u00e7alara ay\u0131rmak i\u00e7in idealdir. Bu sayede sorgular daha okunabilir, bak\u0131m\u0131 daha kolay ve genellikle daha performansl\u0131 hale gelir.<\/p>\nBir CTE'nin temel yap\u0131s\u0131:<\/p>\n
\n WITH CTE_Adi (Sutun1, Sutun2, ...) AS\n (\n SELECT Sutun1, Sutun2 FROM Tablo WHERE Kosul\n )\n SELECT Sutun1, Sutun2 FROM CTE_Adi WHERE BaskaKosul;\n <\/pre>\n<\/code><\/p>\n
CTE'lerin Okunabilirlik ve Performans Katk\u0131lar\u0131<\/h3>\n
CTE'lerin ba\u015fl\u0131ca faydalar\u0131 \u015funlard\u0131r:<\/p>\n
\n- Okunabilirlik:<\/strong> Karma\u015f\u0131k sorgular\u0131 mant\u0131ksal ad\u0131mlara b\u00f6ler, bu da kodun anla\u015f\u0131lmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r.<\/li>\n
- Tekrar Kullan\u0131labilirlik:<\/strong> Bir CTE, ayn\u0131 sorgu i\u00e7inde birden fazla kez referans al\u0131nabilir.<\/li>\n
- \u00d6zyinelemeli Sorgular:<\/strong> Hiyerar\u015fik veri yap\u0131lar\u0131n\u0131 sorgulamak i\u00e7in \u00f6zyinelemeli CTE'ler yazmaya olanak tan\u0131r.<\/li>\n
- Performans (dolayl\u0131):<\/strong> Veritaban\u0131 optimizat\u00f6rleri genellikle CTE'leri alt sorgulardan daha iyi i\u015fleyebilir.<\/li>\n<\/ul>\n
Vaka Analizi: Alt Sorgudan CTE'ye Refactoring<\/h3>\n
Son 3 ayda en \u00e7ok sipari\u015f veren m\u00fc\u015fterileri ve ortalama sipari\u015f de\u011ferini bulmak istedi\u011fimizi varsayal\u0131m. Alt sorgu ile karma\u015f\u0131kla\u015fan bir yap\u0131y\u0131 CTE ile daha anla\u015f\u0131l\u0131r hale getirebiliriz.<\/p>\n
\n -- CTE ile \u0130yi Uygulama\n WITH Son3AySiparisler AS (\n SELECT MusteriID, SiparisID, Tutar\n FROM Siparisler\n WHERE Tarih >= DATEADD(month, -3, GETDATE())\n ),\n MusteriSiparisDetay AS (\n SELECT MusteriID, COUNT(SiparisID) AS ToplamSiparisSayisi, AVG(Tutar) AS OrtalamaSiparisTutari\n FROM Son3AySiparisler\n GROUP BY MusteriID\n )\n SELECT M.MusteriAdi, MSD.ToplamSiparisSayisi, MSD.OrtalamaSiparisTutari\n FROM Musteriler M\n JOIN MusteriSiparisDetay MSD ON M.MusteriID = MSD.MusteriID\n ORDER BY MSD.ToplamSiparisSayisi DESC;\n <\/pre>\n<\/code><\/p>\n
Bu yap\u0131, sorguyu ad\u0131mlara ay\u0131rarak hem daha anla\u015f\u0131l\u0131r hale getirir hem de veritaban\u0131 optimizat\u00f6r\u00fcn\u00fcn daha verimli bir y\u00fcr\u00fctme plan\u0131 olu\u015fturmas\u0131na yard\u0131mc\u0131 olabilir.<\/p>\n
\n Uzman \u0130pucu: Karma\u015f\u0131k mant\u0131klar\u0131 ad\u0131m ad\u0131m \u00e7\u00f6zmek i\u00e7in CTE'leri kullanmaktan \u00e7ekinmeyin. \u00d6zellikle veri gruplama, s\u0131ralama veya hiyerar\u015fik sorgularda CTE'ler, kodunuzu hem basitle\u015ftirir hem de optimize edilebilirli\u011fini art\u0131r\u0131r.\n <\/div>\n\u0130leri D\u00fczey Optimizasyon \u0130pu\u00e7lar\u0131: Ustal\u0131k S\u0131rlar\u0131 Nelerdir?<\/h3>\n
SQL optimizasyonu sadece temel tekniklerle s\u0131n\u0131rl\u0131 de\u011fildir; bazen veritaban\u0131 sisteminin derinliklerine inmek ve daha sofistike yakla\u015f\u0131mlar sergilemek gerekebilir. Bu b\u00f6l\u00fcmde, deneyimli geli\u015ftiriciler ve veritaban\u0131 y\u00f6neticileri i\u00e7in vazge\u00e7ilmez olan ileri d\u00fczey ipu\u00e7lar\u0131n\u0131 ve p\u00fcf noktalar\u0131n\u0131 inceleyece\u011fiz.<\/p>\n
Sorgu Y\u00fcr\u00fctme Plan\u0131 (Execution Plan) Analizi<\/h4>\n
Performans sorunlar\u0131n\u0131n k\u00f6kenine inmenin en kritik yolu, DBMS'nin sorgu y\u00fcr\u00fctme plan\u0131n\u0131 analiz etmektir. Bu plan, veritaban\u0131 optimizat\u00f6r\u00fcn\u00fcn sorgunuzu nas\u0131l \u00e7al\u0131\u015ft\u0131rmay\u0131 d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fc g\u00f6steren bir yol haritas\u0131d\u0131r. Hangi indekslerin kullan\u0131ld\u0131\u011f\u0131n\u0131, hangi tablolar\u0131n tam olarak tarand\u0131\u011f\u0131n\u0131 (Full Table Scan), hangi birle\u015ftirme (JOIN) algoritmalar\u0131n\u0131n se\u00e7ildi\u011fini ve her ad\u0131m\u0131n maliyetini g\u00f6sterir.<\/p>\n
\n- SQL Server:<\/strong> SSMS i\u00e7inde \"Display Estimated Execution Plan\" (Ctrl+L) veya \"Include Actual Execution Plan\" (Ctrl+M) ile g\u00f6rsel bir plan sunar.<\/li>\n
- MySQL:<\/strong>\n
EXPLAIN SELECT ...<\/pre>\n<\/code> komutu metinsel bir \u00e7\u0131kt\u0131 verir.<\/li>\n
- PostgreSQL:<\/strong>\n
EXPLAIN (ANALYZE, VERBOSE) SELECT ...<\/pre>\n<\/code> detayl\u0131 bir analiz sa\u011flar.<\/li>\n<\/ul>\n
Plan\u0131 okurken y\u00fcksek maliyetli operat\u00f6rlere (Table Scan, Index Scan), eksik indekslere ve gereksiz s\u0131ralamalara dikkat edin.<\/p>\n
UNION<\/code> vs UNION ALL<\/code><\/h4>\nBirden fazla SELECT<\/code> sorgusunun sonu\u00e7lar\u0131n\u0131 birle\u015ftirmek i\u00e7in kullan\u0131l\u0131rlar, ancak \u00f6nemli bir performans fark\u0131 vard\u0131r:<\/p>\n\nUNION<\/code>:<\/strong> Yinelenen sat\u0131rlar\u0131 kald\u0131rmak i\u00e7in s\u0131ralama ve tekille\u015ftirme i\u015flemi yapar, bu da maliyetlidir.<\/li>\nUNION ALL<\/code>:<\/strong> Sadece sorgu sonu\u00e7lar\u0131n\u0131 birle\u015ftirir, yinelenen sat\u0131rlar\u0131 kontrol etmez veya kald\u0131rmaz. E\u011fer yinelenen sat\u0131rlar\u0131n olmamas\u0131ndan eminseniz veya varl\u0131\u011f\u0131 sorun de\u011filse, her zaman UNION ALL<\/code> kullan\u0131n. \u00c7ok daha h\u0131zl\u0131d\u0131r.<\/li>\n<\/ul>\nView'lerin Performansa Etkisi<\/h4>\n
View'ler (G\u00f6r\u00fcn\u00fcmler) karma\u015f\u0131k sorgular\u0131 basitle\u015ftirmek i\u00e7in kullan\u0131\u015fl\u0131d\u0131r ancak temel olarak depolanm\u0131\u015f bir sorgudur ve her \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda yeniden \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bu nedenle, View'lerin kendileri performans art\u0131\u015f\u0131 sa\u011flamaz, hatta yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda d\u00fc\u015f\u00fcrebilir. Karma\u015f\u0131k ve i\u00e7 i\u00e7e ge\u00e7mi\u015f View'ler performans\u0131 olumsuz etkileyebilir. Y\u00fcksek performans gereksinimleri varsa, indeksli View (materialized view) veya stored procedure kullanmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz.<\/p>\n
Stored Procedure'lar\u0131n Avantajlar\u0131<\/h4>\n
Stored procedure'lar (Sakl\u0131 Yordamlar), veritaban\u0131nda derlenmi\u015f ve depolanm\u0131\u015f SQL kod bloklar\u0131d\u0131r. Bir\u00e7ok performans avantaj\u0131 sunarlar:<\/p>\n
\n- Derleme ve \u00d6nbellekleme:<\/strong> \u0130lk kez \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda derlenir ve y\u00fcr\u00fctme plan\u0131 \u00f6nbellekte saklan\u0131r.<\/li>\n
- A\u011f Trafi\u011fi Azaltma:<\/strong> Uygulama, tek bir \u00e7a\u011fr\u0131 ile stored procedure'u \u00e7al\u0131\u015ft\u0131rabilir.<\/li>\n
- Parametre G\u00fcvenli\u011fi:<\/strong> SQL Injection sald\u0131r\u0131lar\u0131na kar\u015f\u0131 daha g\u00fcvenlidirler.<\/li>\n<\/ul>\n
LIMIT<\/code> \/ OFFSET<\/code> veya TOP<\/code> Kullan\u0131m\u0131<\/h4>\nB\u00fcy\u00fck veri setlerinden sadece belirli bir k\u0131sm\u0131n\u0131 \u00e7ekmek i\u00e7in sayfaland\u0131rma (pagination) teknikleri kullan\u0131l\u0131r. Bu, hem sunucu kaynaklar\u0131n\u0131 hem de a\u011f trafi\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n
\n -- SQL Server Paging \u00d6rne\u011fi\n SELECT UrunAdi, Fiyat\n FROM Urunler\n ORDER BY UrunID\n OFFSET 100 ROWS -- \u0130lk 100 sat\u0131r\u0131 atla\n FETCH NEXT 10 ROWS ONLY; -- Sonraki 10 sat\u0131r\u0131 getir\n <\/pre>\n<\/code><\/p>\n
Veritaban\u0131 Denormalizasyonu Ne Zaman D\u00fc\u015f\u00fcn\u00fclmeli?<\/h4>\n
Yo\u011fun okuma i\u015flemlerinin oldu\u011fu ve performans\u0131n kritik oldu\u011fu sistemlerde denormalizasyon ge\u00e7ici \u00e7\u00f6z\u00fcmler sunabilir. S\u0131k\u00e7a birlikte sorgulanan verileri tek bir tabloda tutmak, JOIN<\/code> maliyetlerini ortadan kald\u0131rabilir. Ancak denormalizasyon, veri tutarl\u0131l\u0131\u011f\u0131 sorunlar\u0131na yol a\u00e7abilece\u011fi i\u00e7in \u00e7ok dikkatli yap\u0131lmal\u0131d\u0131r.<\/p>\n\n Uzman \u0130pucu: S\u00fcrekli izleme ve test, optimizasyonun vazge\u00e7ilmezidir. Yapt\u0131\u011f\u0131n\u0131z her de\u011fi\u015fikli\u011fin performans \u00fczerindeki ger\u00e7ek etkisini anlamak i\u00e7in mutlaka test edin ve metrikleri takip edin.\n <\/div>\nMobil Uyumlu Veri Sunumu ve SQL \u0130li\u015fkisi: Sonu\u00e7lar\u0131 Nas\u0131l Etkin G\u00f6steririz?<\/h2>\n
G\u00fcn\u00fcm\u00fczde mobil cihazlar \u00fczerinden uygulamalara eri\u015fim yayg\u0131nla\u015ft\u0131\u011f\u0131ndan, geli\u015ftirdi\u011fimiz uygulamalar\u0131n mobil uyumlu olmas\u0131 bir zorunluluktur. SQL kodu optimizasyonu ile mobil uyumlu veri sunumu aras\u0131nda do\u011frudan bir ili\u015fki vard\u0131r. Veritaban\u0131ndan \u00e7ekilen verinin mobil uygulamalarda veya responsive web sitelerinde etkin bir \u015fekilde g\u00f6sterilebilmesi i\u00e7in SQL taraf\u0131nda atabilece\u011fimiz ad\u0131mlar olduk\u00e7a \u00f6nemlidir.<\/p>\n
Mobil uyumlu bir kullan\u0131c\u0131 deneyimi i\u00e7in uygulaman\u0131n h\u0131zl\u0131 yan\u0131t vermesi ve minimum a\u011f trafi\u011fi kullanmas\u0131 kritiktir. Optimize edilmi\u015f SQL, yaln\u0131zca ihtiya\u00e7 duyulan veriyi, en h\u0131zl\u0131 \u015fekilde ve do\u011fru formatta sa\u011flayarak front-end geli\u015ftiricilerinin i\u015fini kolayla\u015ft\u0131r\u0131r ve mobil performans\u0131 do\u011frudan art\u0131r\u0131r.<\/p>\n
Veri Transferini Minimize Etme: Sayfalama ve Filtreleme<\/h3>\n
Mobil cihazlar\u0131n bant geni\u015fli\u011fi k\u0131s\u0131tlamalar\u0131 g\u00f6z \u00f6n\u00fcne al\u0131nd\u0131\u011f\u0131nda, sunucudan istemciye aktar\u0131lan veri miktar\u0131n\u0131 en aza indirmek hayati \u00f6nem ta\u015f\u0131r. Bu, SQL seviyesinde yap\u0131labilecek en temel optimizasyonlardan biridir:<\/p>\n
\n- Sunucu Taraf\u0131 Sayfalama:<\/strong> T\u00fcm veriyi \u00e7ekip client taraf\u0131nda sayfaland\u0131rmak yerine,
LIMIT<\/code>\/OFFSET<\/code> veya OFFSET ... FETCH NEXT ... ROWS ONLY<\/code> gibi ifadeler kullanarak sadece istenen sayfan\u0131n verilerini \u00e7ekmeliyiz.<\/li>\n- Sunucu Taraf\u0131 Filtreleme ve S\u0131ralama:<\/strong> Filtreleme ve s\u0131ralama i\u015flemlerini SQL sorgusunun
WHERE<\/code> ve ORDER BY<\/code> ko\u015fullar\u0131nda yapmak, istemciye sadece filtrelenmi\u015f ve s\u0131ralanm\u0131\u015f nihai verinin g\u00f6nderilmesini sa\u011flar.<\/li>\n- S\u00fctun Se\u00e7imi:<\/strong> Sadece mobil aray\u00fczde g\u00f6sterilecek s\u00fctunlar\u0131 se\u00e7mek, gereksiz veri transferini engeller.<\/li>\n<\/ul>\n
Veri Yap\u0131s\u0131n\u0131 Mobil Uyumlu Hale Getirme<\/h3>\n
Modern veritabanlar\u0131, sorgu sonu\u00e7lar\u0131n\u0131 do\u011frudan JSON format\u0131nda d\u00f6nd\u00fcrme yetene\u011fine sahiptir (\u00f6rne\u011fin, SQL Server'da FOR JSON PATH<\/code>). JSON, web ve mobil uygulamalar taraf\u0131ndan kolayca t\u00fcketilebilen, hiyerar\u015fik bir veri format\u0131d\u0131r. SQL sorgunuzun sonucunu do\u011frudan JSON olarak d\u00f6nd\u00fcrmek, ara katmanda (API katman\u0131) JSON'a d\u00f6n\u00fc\u015ft\u00fcrme maliyetini ortadan kald\u0131rabilir ve veri sunumunu daha verimli hale getirebilir.<\/p>\n\n -- SQL Server \u00f6rne\u011fi: JSON format\u0131nda \u00e7\u0131kt\u0131 alma\n SELECT\n UrunAdi AS 'name',\n Fiyat AS 'price',\n Kategori AS 'category'\n FROM Urunler\n WHERE StokAdedi > 0\n FOR JSON PATH;\n <\/pre>\n<\/code><\/p>\n
Bu \u015fekilde d\u00f6nen JSON verisi, mobil uygulaman\u0131zda veya responsive bir web aray\u00fcz\u00fcnde h\u0131zl\u0131ca i\u015flenebilir. SQL, veriyi optimize ederken, front-end bu veriyi nas\u0131l sunaca\u011f\u0131na karar verir. \u00d6rne\u011fin, bir web uygulamas\u0131nda SQL'den gelen \u00fcr\u00fcn listesi verisini mobil uyumlu bir \u015fekilde g\u00f6stermek i\u00e7in basit CSS medya sorgusu kullanabiliriz:<\/p>\n
\n