thread_cache_size<\/strong><\/td>\n| Tekrar kullan\u0131lmak \u00fczere \u00f6nbelle\u011fe al\u0131nacak i\u015f par\u00e7ac\u0131\u011f\u0131 say\u0131s\u0131.<\/td>\n | Y\u00fcksek ba\u011flant\u0131 oranlar\u0131 i\u00e7in 16-64 aras\u0131.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/span>\u0130\u015f Par\u00e7ac\u0131\u011f\u0131 (Thread) ve Ba\u011flant\u0131 Y\u00f6netimi<\/span><\/h3>\nVeritaban\u0131 sunucusuna yap\u0131lan her ba\u011flant\u0131, sunucu kaynaklar\u0131n\u0131 (bellek ve CPU) t\u00fcketen bir i\u015f par\u00e7ac\u0131\u011f\u0131 (thread) olu\u015fturur. Bu ba\u011flant\u0131lar\u0131n ve i\u015f par\u00e7ac\u0131klar\u0131n\u0131n verimli y\u00f6netimi, sunucunun kararl\u0131l\u0131\u011f\u0131 ve performans\u0131 i\u00e7in zorunludur.<\/p>\n `max_connections` De\u011ferinin Belirlenmesi<\/h4>\nBu parametre, sunucunun ayn\u0131 anda kabul edece\u011fi maksimum istemci ba\u011flant\u0131 say\u0131s\u0131n\u0131 belirler. \u00c7ok d\u00fc\u015f\u00fck bir de\u011fer, uygulaman\u0131n “Too many connections” hatas\u0131 almas\u0131na neden olabilir. \u00c7ok y\u00fcksek bir de\u011fer ise sunucunun belle\u011finin t\u00fckenmesine ve sistemin karars\u0131zla\u015fmas\u0131na yol a\u00e7abilir. Bu de\u011fer, uygulaman\u0131n en yo\u011fun anlardaki ba\u011flant\u0131 ihtiyac\u0131 g\u00f6z \u00f6n\u00fcnde bulundurularak dikkatlice ayarlanmal\u0131d\u0131r. `SHOW GLOBAL STATUS LIKE ‘Max_used_connections’;` komutu ile ge\u00e7mi\u015fteki en y\u00fcksek kullan\u0131m g\u00f6r\u00fclebilir ve bu de\u011ferin biraz \u00fczerinde bir marj b\u0131rak\u0131larak ayar yap\u0131labilir.<\/p>\n `thread_cache_size` ile Performans Art\u0131\u015f\u0131<\/h4>\nYeni bir ba\u011flant\u0131 geldi\u011finde, MySQL ya yeni bir i\u015f par\u00e7ac\u0131\u011f\u0131 olu\u015fturur ya da \u00f6nbellekten (cache) mevcut bir tanesini kullan\u0131r. \u0130\u015f par\u00e7ac\u0131\u011f\u0131 olu\u015fturmak maliyetli bir i\u015flemdir. `thread_cache_size` parametresi, ba\u011flant\u0131 kapand\u0131ktan sonra ka\u00e7 tane i\u015f par\u00e7ac\u0131\u011f\u0131n\u0131n tekrar kullan\u0131lmak \u00fczere \u00f6nbellekte tutulaca\u011f\u0131n\u0131 belirler. \u00d6zellikle s\u0131k s\u0131k k\u0131sa s\u00fcreli ba\u011flant\u0131lar\u0131n a\u00e7\u0131l\u0131p kapand\u0131\u011f\u0131 web uygulamalar\u0131 i\u00e7in bu de\u011feri art\u0131rmak, CPU kullan\u0131m\u0131n\u0131 azaltarak performans\u0131 olumlu etkiler.<\/p>\n <\/span>Sorgu \u00d6nbelle\u011fi (Query Cache): Avantajlar\u0131, Dezavantajlar\u0131 ve Modern Alternatifler<\/span><\/h3>\nMySQL’in eski s\u00fcr\u00fcmlerinde pop\u00fcler olan Sorgu \u00d6nbelle\u011fi (Query Cache), ayn\u0131 olan sorgular\u0131n sonu\u00e7lar\u0131n\u0131 bellekte saklayarak tekrar \u00e7al\u0131\u015ft\u0131r\u0131lmalar\u0131n\u0131 engellemeyi ama\u00e7l\u0131yordu. Teoride harika bir fikir olsa da pratikte, \u00f6zellikle yazma yo\u011funlu\u011fu y\u00fcksek tablolarda, \u00f6nbelle\u011fi s\u00fcrekli ge\u00e7ersiz k\u0131lma maliyeti (invalidation overhead) nedeniyle bir performans darbo\u011faz\u0131na d\u00f6n\u00fc\u015f\u00fcyordu. Bu nedenle MySQL 8.0 ve sonras\u0131 s\u00fcr\u00fcmlerden tamamen kald\u0131r\u0131lm\u0131\u015ft\u0131r. Modern yakla\u015f\u0131mlar, veritaban\u0131 seviyesinde sorgu \u00f6nbellekleme yerine Redis veya Memcached gibi harici \u00f6nbellekleme sistemlerini uygulama katman\u0131nda kullanmay\u0131 tercih eder. Bu yakla\u015f\u0131m, neyin ne kadar s\u00fcreyle \u00f6nbelle\u011fe al\u0131naca\u011f\u0131 konusunda daha fazla esneklik ve kontrol sa\u011flar.<\/p>\n <\/span>Loglama Ayarlar\u0131n\u0131n Performansa Etkisi<\/span><\/h3>\nLoglama (g\u00fcnl\u00fck tutma), sorun giderme ve performans analizi i\u00e7in paha bi\u00e7ilmezdir, ancak a\u015f\u0131r\u0131 loglama disk I\/O’sunu art\u0131rarak performans\u0131 olumsuz etkileyebilir. Bu nedenle loglama ayarlar\u0131n\u0131n dengeli bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 gerekir.<\/p>\n Yava\u015f Sorgu G\u00fcnl\u00fc\u011f\u00fc (Slow Query Log) ile Sorun Tespiti<\/h4>\nYava\u015f Sorgu G\u00fcnl\u00fc\u011f\u00fc, optimizasyon s\u00fcrecinin en de\u011ferli ara\u00e7lar\u0131ndan biridir. Belirlenen bir s\u00fcreden (`long_query_time`) daha uzun s\u00fcren sorgular\u0131 bir dosyaya kaydeder. Bu logu aktif hale getirerek, uygulaman\u0131zda performans sorunlar\u0131na yol a\u00e7an spesifik sorgular\u0131 kolayca tespit edebilir ve iyile\u015ftirme \u00e7al\u0131\u015fmalar\u0131n\u0131z\u0131 bu sorgulara odaklayabilirsiniz. \u00dcretim ortamlar\u0131nda bu logun s\u00fcrekli a\u00e7\u0131k olmas\u0131 genellikle tavsiye edilir.<\/p>\n Genel G\u00fcnl\u00fck (General Log) ve Hata G\u00fcnl\u00fc\u011f\u00fc (Error Log) Y\u00f6netimi<\/h4>\nGenel G\u00fcnl\u00fck (General Log), sunucuya gelen her sorguyu kaydeder. Bu, hata ay\u0131klama s\u0131ras\u0131nda faydal\u0131 olsa da y\u00fcksek trafikli sistemlerde \u00e7ok b\u00fcy\u00fck bir disk I\/O y\u00fck\u00fc olu\u015fturur ve performans\u0131 ciddi \u015fekilde d\u00fc\u015f\u00fcr\u00fcr. Bu nedenle sadece k\u0131sa s\u00fcreli hata ay\u0131klama i\u015flemleri i\u00e7in a\u00e7\u0131lmal\u0131 ve sonras\u0131nda kapat\u0131lmal\u0131d\u0131r. Hata G\u00fcnl\u00fc\u011f\u00fc (Error Log) ise sunucunun ba\u015flat\u0131lmas\u0131, durdurulmas\u0131 ve \u00e7al\u0131\u015fma s\u0131ras\u0131nda kar\u015f\u0131la\u015ft\u0131\u011f\u0131 kritik hatalar\u0131 kaydeder. Performans \u00fczerinde minimum etkiye sahiptir ve her zaman aktif olmal\u0131d\u0131r.<\/p>\n <\/span>\u015eema Tasar\u0131m\u0131 ve Veri Tipi Optimizasyonu<\/span><\/h2>\nVeritaban\u0131 performans\u0131, sadece sunucu ayarlar\u0131 ve donan\u0131mla s\u0131n\u0131rl\u0131 de\u011fildir. Performans\u0131n temeli, daha ilk tablo olu\u015fturulurken at\u0131l\u0131r. Ak\u0131ll\u0131ca tasarlanm\u0131\u015f bir veritaban\u0131 \u015femas\u0131, do\u011fru se\u00e7ilmi\u015f veri tipleri ve uygun depolama motoru, sorgular\u0131n daha h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131, verilerin daha az yer kaplamas\u0131n\u0131 ve sistemin genel olarak daha verimli olmas\u0131n\u0131 sa\u011flar. Bu b\u00f6l\u00fcm, optimizasyonun temel ta\u015flar\u0131n\u0131 olu\u015fturan bu tasar\u0131m kararlar\u0131n\u0131 ele almaktad\u0131r.<\/p>\n <\/span>Do\u011fru Veri Tiplerini Se\u00e7menin Performansa Etkisi (INT, VARCHAR, TEXT vb.)<\/span><\/h3>\nHer s\u00fctun i\u00e7in m\u00fcmk\u00fcn olan en k\u00fc\u00e7\u00fck ve en uygun veri tipini se\u00e7mek, performans\u0131 do\u011frudan etkiler. \u00d6rne\u011fin, 1 ile 200 aras\u0131nda bir de\u011feri saklayacak bir s\u00fctun i\u00e7in `INT` (4 byte) yerine `TINYINT UNSIGNED` (1 byte) kullanmak, sat\u0131r ba\u015f\u0131na 3 byte tasarruf sa\u011flar. Milyonlarca sat\u0131rl\u0131k bir tabloda bu, megabytelarca daha k\u00fc\u00e7\u00fck bir tablo, daha verimli bellek kullan\u0131m\u0131 ve daha h\u0131zl\u0131 yedekleme i\u015flemleri demektir. Benzer \u015fekilde, sabit uzunlukta olmayan metinler i\u00e7in, maksimum uzunluk ne olacaksa `VARCHAR` tan\u0131m\u0131n\u0131 ona g\u00f6re yapmak (\u00f6rne\u011fin `VARCHAR(255)` yerine `VARCHAR(50)`) \u00f6nemlidir. Daha b\u00fcy\u00fck metinler i\u00e7in ise `TEXT` veya `BLOB` tipleri kullan\u0131lmal\u0131d\u0131r.<\/p>\n <\/span>Normalizasyon ve Denormalizasyon Aras\u0131ndaki Denge<\/span><\/h3>\nNormalizasyon<\/b>, veri tekrar\u0131n\u0131 ortadan kald\u0131rmak ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flamak i\u00e7in veriyi birden fazla tabloya b\u00f6lme i\u015flemidir. Bu, yazma i\u015flemlerini (INSERT, UPDATE, DELETE) daha h\u0131zl\u0131 ve tutarl\u0131 hale getirir. Ancak, okuma i\u015flemleri s\u0131ras\u0131nda veriyi bir araya getirmek i\u00e7in \u00e7ok say\u0131da `JOIN` i\u015flemi gerektirebilir. Denormalizasyon<\/b> ise tam tersine, performans\u0131 art\u0131rmak amac\u0131yla baz\u0131 verileri kas\u0131tl\u0131 olarak tekrarlayarak `JOIN` ihtiyac\u0131n\u0131 azaltma tekni\u011fidir. \u00d6rne\u011fin, s\u0131k\u00e7a kullan\u0131lan bir kategori ad\u0131n\u0131, her seferinde kategoriler tablosuna `JOIN` yapmamak i\u00e7in \u00fcr\u00fcnler tablosuna da eklemek bir denormalizasyon \u00f6rne\u011fidir. Modern veritaban\u0131 tasar\u0131m\u0131nda ama\u00e7, bu iki yakla\u015f\u0131m aras\u0131nda do\u011fru dengeyi kurmakt\u0131r. Genellikle, y\u00fcksek normalizasyonla ba\u015flan\u0131r ve performans darbo\u011fazlar\u0131 tespit edildik\u00e7e belirli alanlarda kontroll\u00fc denormalizasyon uygulan\u0131r.<\/p>\n<\/span>Depolama Motoru (Storage Engine) Se\u00e7imi: InnoDB vs. MyISAM<\/span><\/h3>\nMySQL ve MariaDB, farkl\u0131 ihtiya\u00e7lara y\u00f6nelik \u00e7e\u015fitli depolama motorlar\u0131 sunar. En yayg\u0131n kullan\u0131lan ikisi InnoDB ve MyISAM’dir ve aralar\u0131ndaki se\u00e7im, uygulaman\u0131n gereksinimlerine ba\u011fl\u0131 olarak performans\u0131 k\u00f6kten etkiler.<\/p>\n \n- InnoDB:<\/b> Varsay\u0131lan depolama motorudur. ACID uyumlulu\u011fu, sat\u0131r seviyesinde kilitleme (row-level locking), \u00e7\u00f6kme kurtarma (crash recovery) ve yabanc\u0131 anahtar (foreign key) deste\u011fi gibi \u00f6zelliklere sahiptir. Bu da onu y\u00fcksek yazma\/okuma trafi\u011fi olan, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn kritik oldu\u011fu ve e\u015fzamanl\u0131 i\u015flemlerin yo\u011fun oldu\u011fu (\u00f6rne\u011fin, e-ticaret siteleri, bankac\u0131l\u0131k uygulamalar\u0131) sistemler i\u00e7in ideal k\u0131lar.<\/li>\n
- MyISAM:<\/b> Eski varsay\u0131lan motordur. \u0130\u015flem (transaction) veya yabanc\u0131 anahtar deste\u011fi yoktur. Tablo seviyesinde kilitleme (table-level locking) kullan\u0131r, bu da birden fazla kullan\u0131c\u0131n\u0131n ayn\u0131 anda tabloya yazma yapmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumlarda performans d\u00fc\u015f\u00fc\u015f\u00fcne neden olur. Ancak, sadece okuma yap\u0131lan (read-heavy) ve `COUNT(*)` gibi tam tablo say\u0131m i\u015flemlerinin \u00e7ok s\u0131k yap\u0131ld\u0131\u011f\u0131 basit uygulamalar veya veri ambarlar\u0131 i\u00e7in hala h\u0131zl\u0131 bir se\u00e7enek olabilir.<\/li>\n<\/ul>\n
\n \n\n\n| \u00d6zellik<\/th>\n | InnoDB<\/th>\n | MyISAM<\/th>\n<\/tr>\n<\/thead>\n | \n\nVarsay\u0131lan Motor<\/strong><\/td>\n| Evet (MySQL 5.5+ sonras\u0131)<\/td>\n | Hay\u0131r (Eski s\u00fcr\u00fcmlerde evet)<\/td>\n<\/tr>\n | \n\u0130\u015flem Deste\u011fi (ACID)<\/strong><\/td>\n| Evet<\/td>\n | Hay\u0131r<\/td>\n<\/tr>\n | \nKilitleme Seviyesi<\/strong><\/td>\n| Sat\u0131r Seviyesi<\/td>\n | Tablo Seviyesi<\/td>\n<\/tr>\n | \nYabanc\u0131 Anahtar Deste\u011fi<\/strong><\/td>\n| Evet<\/td>\n | Hay\u0131r<\/td>\n<\/tr>\n | \n\u00c7\u00f6kme Kurtarma<\/strong><\/td>\n| Evet (Daha g\u00fcvenilir)<\/td>\n | Hay\u0131r (Manuel onar\u0131m gerekebilir)<\/td>\n<\/tr>\n | \nTam Metin Arama<\/strong><\/td>\n| Evet (MySQL 5.6+)<\/td>\n | Evet<\/td>\n<\/tr>\n | \n\u0130deal Kullan\u0131m Alan\u0131<\/strong><\/td>\n| Y\u00fcksek i\u015flem hacimli, veri b\u00fct\u00fcnl\u00fc\u011f\u00fc kritik olan t\u00fcm modern uygulamalar.<\/td>\n | Okuma a\u011f\u0131rl\u0131kl\u0131, basit ve eski tip uygulamalar.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/span>Karakter Setleri (Character Sets) ve Kar\u015f\u0131la\u015ft\u0131rma (Collations) Ayarlar\u0131<\/span><\/h3>\nKarakter seti, veritaban\u0131n\u0131n hangi karakterleri (harfler, say\u0131lar, semboller) saklayabildi\u011fini tan\u0131mlar. Kar\u015f\u0131la\u015ft\u0131rma (collation) ise bu karakterlerin nas\u0131l s\u0131ralanaca\u011f\u0131n\u0131 ve kar\u015f\u0131la\u015ft\u0131r\u0131laca\u011f\u0131n\u0131 belirler (\u00f6rne\u011fin b\u00fcy\u00fck\/k\u00fc\u00e7\u00fck harf duyarl\u0131l\u0131\u011f\u0131). Modern uygulamalar i\u00e7in evrensel uyumluluk sa\u011flayan `utf8mb4` karakter setini kullanmak en iyi pratiktir. Yanl\u0131\u015f karakter seti se\u00e7imi, veri kayb\u0131na veya beklenmedik hatalara yol a\u00e7abilir. Performans a\u00e7\u0131s\u0131ndan, t\u00fcm tablolar\u0131n ve ba\u011flant\u0131lar\u0131n ayn\u0131 karakter setini kullanmas\u0131, gereksiz karakter seti d\u00f6n\u00fc\u015f\u00fcmlerini engelleyerek k\u00fc\u00e7\u00fck de olsa bir performans art\u0131\u015f\u0131 sa\u011flar.<\/p>\n <\/span>\u0130ndeksleme Stratejileri ve En \u0130yi Pratikler<\/span><\/h2>\nVeritaban\u0131 performans optimizasyonunda en b\u00fcy\u00fck etkiyi yaratan tekniklerden biri \u015f\u00fcphesiz do\u011fru ve etkili indeksleme yapmakt\u0131r. \u0130ndeksler olmasayd\u0131, veritaban\u0131 bir sorguyu yan\u0131tlamak i\u00e7in tablodaki her bir sat\u0131r\u0131 ba\u015ftan sona taramak zorunda kal\u0131rd\u0131. Bu, k\u00fc\u00e7\u00fck tablolarda fark edilmese de milyonlarca sat\u0131rl\u0131k tablolarda dakikalar, hatta saatler s\u00fcrebilir. \u0130ndeksler, bu arama s\u00fcrecini logaritmik bir h\u0131za indirerek performans\u0131 katbekat art\u0131r\u0131r.<\/p>\n <\/span>\u0130ndeks Nedir ve Sorgu Performans\u0131n\u0131 Nas\u0131l Art\u0131r\u0131r?<\/span><\/h3>\nBir veritaban\u0131 indeksi, bir kitab\u0131n sonundaki dizine (indeks) \u00e7ok benzer. Belirli bir konuyu bulmak i\u00e7in t\u00fcm kitab\u0131 okumak yerine, dizine bakarak o konunun hangi sayfada oldu\u011funu an\u0131nda bulabilirsiniz. Benzer \u015fekilde, bir veritaban\u0131 indeksi de bir veya daha fazla s\u00fctundaki verileri s\u0131ral\u0131 bir yap\u0131da tutar. Bir sorgu geldi\u011finde, veritaban\u0131 t\u00fcm tabloyu taramak yerine bu s\u0131ral\u0131 indeks yap\u0131s\u0131n\u0131 kullanarak aranan verinin diskteki konumuna do\u011frudan ve \u00e7ok h\u0131zl\u0131 bir \u015fekilde eri\u015fir. Bu, \u00f6zellikle b\u00fcy\u00fck tablolardaki arama (`SELECT`) i\u015flemlerini dramatik \u00f6l\u00e7\u00fcde h\u0131zland\u0131r\u0131r.<\/p>\n <\/span>\u0130ndeks T\u00fcrleri ve Kullan\u0131m Alanlar\u0131 (B-Tree, Full-text, Spatial)<\/span><\/h3>\nMySQL ve MariaDB, farkl\u0131 sorgu t\u00fcrleri i\u00e7in optimize edilmi\u015f \u00e7e\u015fitli indeks t\u00fcrleri sunar:<\/p>\n \n- B-Tree \u0130ndeksi:<\/b> En yayg\u0131n kullan\u0131lan indeks t\u00fcr\u00fcd\u00fcr. E\u015fitlik (`=`), aral\u0131k (`<`, `>`, `BETWEEN`), ve `LIKE` (joker karakter ba\u015fta olmad\u0131\u011f\u0131nda) gibi kar\u015f\u0131la\u015ft\u0131rma operat\u00f6rlerini kullanan sorgular i\u00e7in idealdir. Neredeyse t\u00fcm depolama motorlar\u0131 taraf\u0131ndan desteklenir.<\/li>\n
- Full-text (Tam Metin) \u0130ndeksi:<\/b> Uzun metin bloklar\u0131 (`TEXT`, `VARCHAR`) i\u00e7inde anahtar kelime aramalar\u0131 yapmak i\u00e7in kullan\u0131l\u0131r. Standart B-Tree indekslerinin etkisiz oldu\u011fu, makale veya \u00fcr\u00fcn a\u00e7\u0131klamalar\u0131 gibi alanlarda karma\u015f\u0131k metin aramalar\u0131n\u0131 (`MATCH … AGAINST`) \u00e7ok h\u0131zl\u0131 bir \u015fekilde ger\u00e7ekle\u015ftirir.<\/li>\n
- Spatial (Mekansal) \u0130ndeksi:<\/b> Co\u011frafi verileri (\u00f6rne\u011fin enlem, boylam) indekslemek ve mekansal sorgular\u0131 (\u00f6rne\u011fin “belirli bir noktaya 5 km yak\u0131nl\u0131ktaki yerler”) verimli bir \u015fekilde \u00e7al\u0131\u015ft\u0131rmak i\u00e7in kullan\u0131l\u0131r. Genellikle harita tabanl\u0131 uygulamalarda tercih edilir.<\/li>\n<\/ul>\n
<\/span>Etkili \u0130ndeksleme \u0130\u00e7in Temel Kurallar<\/span><\/h3>\nDo\u011fru s\u00fctunlara indeks eklemek, performans\u0131 art\u0131rman\u0131n anahtar\u0131d\u0131r. \u0130ndeksler, yazma i\u015flemlerini (INSERT, UPDATE, DELETE) yava\u015flatma potansiyeline sahip oldu\u011fundan, sadece ger\u00e7ekten ihtiya\u00e7 duyulan yerlere eklenmelidir.<\/p>\n `WHERE` ve `JOIN` C\u00fcmlelerinde Kullan\u0131lan S\u00fctunlar\u0131 \u0130ndeksleme<\/h4>\n\u0130ndeksleme i\u00e7in en bariz ve en \u00f6nemli adaylar, sorgular\u0131n `WHERE` ko\u015fullar\u0131nda ve tablolar\u0131 birle\u015ftirmek i\u00e7in kullan\u0131lan `JOIN … ON` c\u00fcmlelerindeki s\u00fctunlard\u0131r. \u00d6rne\u011fin, `SELECT * FROM kullanicilar WHERE sehir = ‘Istanbul’;` sorgusunu h\u0131zland\u0131rmak i\u00e7in `sehir` s\u00fctununa bir indeks eklenmelidir. Benzer \u015fekilde, `SELECT * FROM siparisler JOIN musteriler ON siparisler.musteri_id = musteriler.id;` sorgusunda hem `siparisler.musteri_id` hem de `musteriler.id` (genellikle primary key oldu\u011fu i\u00e7in zaten indekslidir) s\u00fctunlar\u0131 indekslenmelidir.<\/p>\n \u0130ndeks Se\u00e7icili\u011fi (Index Selectivity) Kavram\u0131<\/h4>\n\u0130ndeks se\u00e7icili\u011fi, bir s\u00fctundaki farkl\u0131 (unique) de\u011ferlerin toplam sat\u0131r say\u0131s\u0131na oran\u0131n\u0131 ifade eder. Se\u00e7icili\u011fi y\u00fcksek bir s\u00fctun, \u00e7ok say\u0131da farkl\u0131 de\u011fere sahiptir (\u00f6rne\u011fin, kullan\u0131c\u0131 e-posta adresi). Se\u00e7icili\u011fi d\u00fc\u015f\u00fck bir s\u00fctun ise az say\u0131da farkl\u0131 de\u011fere sahiptir (\u00f6rne\u011fin, cinsiyet ‘Erkek’\/’Kad\u0131n’). \u0130ndeksler, se\u00e7icili\u011fi y\u00fcksek olan s\u00fctunlarda en verimli \u015fekilde \u00e7al\u0131\u015f\u0131r. \u00c7\u00fcnk\u00fc veritaban\u0131, arama sonucunda bakmas\u0131 gereken sat\u0131r say\u0131s\u0131n\u0131 ciddi \u00f6l\u00e7\u00fcde azaltabilir. Cinsiyet gibi d\u00fc\u015f\u00fck se\u00e7icili\u011fe sahip bir s\u00fctuna indeks eklemek, genellikle performansa \u00e7ok az katk\u0131 sa\u011flar veya hi\u00e7 sa\u011flamaz.<\/p>\n | | | | | | | | |