Database Index Nedir, Sorguları Nasıl Hızlandırır?

Database Index (Veritabanı İndeksi), modern veri altyapılarında veri erişim hızını artırmak ve disk okuma yükünü (Disk I/O) minimize etmek amacıyla tasarlanmış kritik bir veri yapısıdır. Özellikle yüksek trafikli enterprise sistemlerde, sorgu performansını optimize etmek ve sunucu kaynaklarını verimli kullanmak doğrudan doğru kurulmuş bir veritabanı indeksleme stratejisine bağlıdır. Bu rehberimizde, database index kavramının ne olduğunu, arka planda çalışan algoritmaları, farklı indeks türlerini ve veri odaklı işletmelerin uygulaması gereken stratejik yaklaşımları teknik ve kurumsal bir ciddiyetle ele alıyoruz.

Database Index (Veritabanı İndeksi) Temel Olarak Nedir?

Veritabanlarında veri, disk üzerinde "page" (sayfa) adı verilen veri bloklarında saklanır. Bir veritabanı tablosuna indeks tanımlanmadığında, herhangi bir arama veya filtreleme işlemi yapıldığında veritabanı yönetim sistemi (DBMS) tablonun başından sonuna kadar tüm sayfaları okumak zorunda kalır. Bu durum, teknik literatürde Full Table Scan olarak adlandırılır. Milyonlarca satırdan oluşan kurumsal ölçekli bir tabloda tek bir kaydı bulmak için tüm diski taramak, disk okuma yazma kafasının (Disk I/O) aşırı yüklenmesine, işlemci kaynaklarının tükenmesine ve nihayetinde sistemin kilitlenmesine yol açar.

Database Index, bu kaotik arama sürecini ortadan kaldırmak için oluşturulmuş, tablodaki belirli kolonların değerlerini ve bu değerlerin disk üzerindeki fiziksel adreslerini (pointer/işaretçi) içeren ayrı bir veri yapısıdır. En temel analojiyle, kalın bir teknik kitabın en arkasında yer alan "Fihrist" (Index) bölümü gibidir. Kitap içinde belirli bir konuyu veya kelimeyi bulmak için tüm sayfaları tek tek okumak yerine, fihriste bakıp konunun hangi sayfada olduğunu öğrenir ve doğrudan o sayfayı açarsınız. Veritabanı indeksleri de SQL sorgularındaki WHERE, JOIN, ORDER BY veya GROUP BY gibi koşullarda kullanılan kolonlar üzerinde bu fihrist yapısını inşa ederek sorguların doğrudan hedef veri bloklarına yönlenmesini sağlar.

Teknik karar vericiler ve sistem mimarları için indeksleme, sadece bir veritabanı optimizasyonu adımı değil, aynı zamanda operasyonel maliyet yönetimidir. Bulut bilişim altyapılarında (AWS RDS, Google Cloud SQL, Microsoft Azure SQL vb.) maliyetler büyük ölçüde işlemci (vCPU), bellek (RAM) ve I/O operasyonlarının (IOPS) tüketimine göre belirlenir. Yanlış veya eksik yapılandırılmış indeksler yüzünden saniyeler süren sorgular, veritabanı sunucusunun kaynak sınırlarını zorlayarak daha pahalı sunucu paketlerine geçiş yapma zorunluluğu doğurur. Doğru bir indeks mimarisi ise aynı donanım üzerinde on kat daha fazla kullanıcıya, milisaniyeler seviyesinde gecikme (latency) süreleriyle hizmet vermeyi mümkün kılar.

Full Table Scan (Tam Tablo Taraması) Problemi

Full Table Scan, veritabanı motorunun aranan kriterlere uygun satırları bulabilmek için ilgili tablonun diskteki tüm bloklarını (data pages) sırayla okuması işlemidir. Küçük tablolarda (örneğin birkaç bin satırlık parametre tablolarında) bu işlem nanosaniyeler içinde tamamlandığı için bir sorun teşkil etmez. Hatta Query Optimizer (Sorgu Optimize Edici), küçük tablolarda indeks okuma maliyetini diski doğrudan okuma maliyetinden yüksek bularak bilerek tam tablo taramasını tercih edebilir. Ancak veri hacmi gigabaytlar veya terabaytlar seviyesine ulaştığında, bu tarama işlemi tam anlamıyla bir performans felaketine dönüşür.

Sistem kaynakları açısından Full Table Scan işleminin yarattığı en büyük tehdit Disk I/O darboğazıdır. Sabit diskler (HDD) veya modern katı hal sürücüleri (SSD) saniyede gerçekleştirebilecekleri okuma/yazma işlemi (IOPS) açısından fiziksel sınırlara sahiptir. İndekssiz bir tabloda yapılan karmaşık bir SELECT sorgusu, milyonlarca disk sayfasını RAM'e taşımaya çalışır. Bu durum, veritabanının en kritik performans unsuru olan Buffer Pool (RAM'deki veri önbelleği) alanını kirletir. Sık kullanılan ve bellekte tutulması gereken veriler diskten yeni okunan yığın veriler yüzünden RAM'den atılır. Sonuç olarak, sadece o sorguyu çalıştıran kullanıcı değil, sistemdeki tüm kullanıcılar yavaşlama hissetmeye başlar.

Full Table Scan probleminin kurumsal sistemlerdeki bir diğer yıkıcı etkisi ise kilitlenmelerdir (Locks). Birçok ilişkisel veritabanı yönetim sistemi (RDBMS), tam tablo taraması esnasında veri tutarlılığını korumak adına taranan satırlar veya tüm tablo üzerinde paylaşımlı kilitler (Shared Locks) oluşturur. Bu kilitler aktifken, aynı tabloya yeni bir veri eklemek (INSERT) veya mevcut bir veriyi güncellemek (UPDATE) isteyen diğer işlemler beklemeye alınır (Queue). Yoğun e-ticaret sitelerinde veya finansal uygulamalarda bu kuyrukların birikmesi, bağlantı havuzunun (Connection Pool) dolmasına ve sistemin tamamen yanıt veremez hale gelmesine neden olur.

---

Database Index Sorguları Nasıl Hızlandırır? (Çalışma Mantığı)

Veritabanı indekslerinin sorguları nasıl hızlandırdığını anlamak, Query Optimizer ve execution plan (sorgu yürütme planı) kavramlarını anlamaktan geçer. Bir kullanıcı SQL sorgusunu çalıştırdığında, veritabanı motoru bu sorguyu doğrudan çalıştırmaz. İlk olarak sorgu derlenir, ardından Query Optimizer adı verilen zeki mekanizma devreye girer. Optimizer, tablodaki veri dağılım istatistiklerini analiz ederek sorgunun en düşük maliyetle (en az işlemci ve disk okumasıyla) nasıl çalıştırılacağını hesaplar. Eğer sorguda filtrelenen kolonlar üzerinde geçerli bir indeks varsa, Optimizer veriyi çekmek için diski boydan boya taramak yerine "Index Seek" veya "Index Scan" yöntemlerini içeren bir execution plan hazırlar.

"Index Seek" işlemi, indeks yapısının en tepesinden başlayarak doğrudan hedeflenen değere ulaşma sürecidir. Bu işlem, veritabanının tüm tabloyu taramadan, sadece aranan kriterle eşleşen birkaç disk sayfasını okumasını sağlar. Örneğin, 10 milyon kayıtlık bir müşteri tablosunda müşteri ID'sine göre bir arama yapıldığında, indeks kullanılarak sadece 3 veya 4 disk okuması (I/O) ile ilgili satıra ulaşılabilir. İndeks kullanılmadığında ise 10 milyon satırın bulunduğu yüz binlerce veri sayfası tek tek okunacaktır. İndeksin sağladığı bu devasa I/O tasarrufu, sorgu yanıt sürelerini dakikalardan milisaniyeler seviyesine indiren temel güçtür.

Disk I/O yükünün minimize edilmesi, aynı zamanda bellek (RAM) yönetimini de doğrudan optimize eder. Veritabanları sık erişilen disk sayfalarını RAM'deki önbellekte (Buffer Pool) tutmaya çalışır. İndeks sayesinde sadece sorgunun ihtiyaç duyduğu minimal veri sayfaları diske gidilerek okunur ve RAM'e yüklenir. Bu sayede bellek kirliliği önlenir, önbellek isabet oranı (Buffer Cache Hit Ratio) %99'un üzerinde kalır ve sistem genelinde kararlı, yüksek performanslı bir çalışma ortamı elde edilir.

B-Tree (B-Ağacı) Mimarisi ve Veri Erişim Hızı | Disk Okuma (I/O) Yükünün Minimize Edilmesi

İlişkisel veritabanlarının (PostgreSQL, MySQL, Oracle, SQL Server) ezici bir çoğunluğu, indeksleme mekanizması için varsayılan olarak B-Tree (Balanced Tree / Dengeli Ağaç) veri yapısını kullanır. B-Tree, verileri sıralı bir şekilde tutan ve arama, ekleme, silme operasyonlarını logaritmik zaman karmaşıklığında ($O(\log n)$) gerçekleştiren bir ağaç veri yapısıdır. Bu yapı, her düğümün (node) birden fazla alt düğüme sahip olabildiği ve tüm yaprak düğümlerin (leaf nodes) aynı derinlikte/seviyede kaldığı dengeli bir hiyerarşi sunar.

B-Tree mimarisi temelde üç katmandan oluşur:

1. Root Node (Kök Düğüm): Arama işleminin başladığı en üst katmandır. Alt düğümlere giden aralıkları (pointer) barındırır.

2. Intermediate Nodes (Ara/Dal Düğümler): Kök düğüm ile yaprak düğümler arasında köprü görevi görür. Arama alanını daraltmak için yönlendirici görevi üstlenirler.

3. Leaf Nodes (Yaprak Düğümler): En alt katmandır. Bu düğümler, indekslenen kolonun gerçek değerlerini ve bu değerlerin ait olduğu satırların fiziksel disk adreslerini (RID) veya Clustered Index anahtarlarını saklar. Yaprak düğümler birbirine çift yönlü bağlı liste (doubly linked list) şeklinde bağlıdır; bu sayede aralık sorguları (BETWEEN, >, <) son derece hızlı bir şekilde gerçekleştirilir.

B-Tree arama algoritmasının disk okuma yükünü nasıl minimize ettiğini bir örnekle somutlaştıralım. Elimizde 1.000.000 satırlık bir tablo olsun ve her disk sayfası (Page) 100 satır veya indeks kaydı barındırabilsin.

B-Tree yapısının her düğümü (sayfası) yüzlerce dal barındırabilir (bu duruma "high fan-out" denir). Yüksek dallanma katsayısı sayesinde, milyarlarca satırdan oluşan devasa tablolarda bile ağacın derinliği genellikle 4 veya 5 katmanı geçmez. Bu, veritabanı motorunun milyarlarca kayıt arasından aradığınız veriyi bulmak için disk üzerinde en fazla 4-5 kez zıplama (I/O işlemi) yapacağı anlamına gelir. Bu logaritmik performans artışı, veritabanı ölçeklenebilirliğinin (scalability) arkasındaki yegane matematiksel gerçektir.

---

Bilinmesi Gereken Temel İndeks (Index) Türleri

Veritabanı tasarımı yaparken her arama senaryosuna aynı indeks yapısını uygulamak ciddi kaynak israfına ve performans kayıplarına yol açar. Farklı sorgu kalıpları, veri dağılımları ve tablo yapıları için özel olarak optimize edilmiş indeks türlerinin tercih edilmesi gerekir. İlişkisel veritabanı mimarisinde en sık kullanılan ve her profesyonel geliştiricinin ile veritabanı yöneticisinin (DBA) derinlemesine bilmesi gereken üç ana indeks kategorisi bulunmaktadır: Clustered Index, Non-Clustered Index ve Composite Index.

Bu indekslerin disk üzerindeki fiziksel yerleşimi, depolama biçimleri ve sorgu motoru tarafından ele alınış şekilleri birbirinden tamamen farklıdır. Bir indeks türü belirli bir okuma sorgusunu milisaniyeler içinde çözerken, yanlış yapılandırıldığında yazma operasyonlarının darboğaza girmesine neden olabilir. Bu nedenle indeks türlerinin yapısal çalışma prensiplerini bilmek, kurumsal veri modellerinin doğru kurgulanması için hayati önem taşır.

Clustered Index (Kümelenmiş İndeks) | Non-Clustered Index (Kümelenmemiş İndeks) | Composite Index (Bileşik İndeks)

Clustered Index (Kümelenmiş İndeks)

Clustered Index, tablodaki satırların disk üzerindeki fiziksel depolama sırasını belirleyen indeks türüdür. Başka bir deyişle, tablonun kendisi bu indeksin yapısına göre fiziksel olarak sıralanır ve saklanır. Bu nedenle, bir tabloda sadece bir adet Clustered Index bulunabilir; çünkü bir veri kümesi disk üzerinde fiziksel olarak aynı anda sadece tek bir kritere göre (örneğin ID veya tarihe göre) sıralı durabilir.

• Nasıl Çalışır?: B-Tree yapısının yaprak düğümleri (leaf nodes), doğrudan tablonun gerçek veri satırlarını (data rows) barındırır. Ekstra bir disk adresine yönlendirme yapılmaz.

• Varsayılan Durum: İlişkisel veritabanlarında (özellikle MySQL InnoDB ve MS SQL Server'da), bir tablo üzerinde PRIMARY KEY (Birincil Anahtar) tanımlandığında, veritabanı motoru bu kolon üzerinde otomatik olarak bir Clustered Index oluşturur.

• En Uygun Senaryolar: Belirli bir aralıktaki verileri çeken (BETWEEN, <, >) veya sıralı veri getiren (ORDER BY) sorgular için olağanüstü performans sağlar. Çünkü veriler diskte yan yana fiziksel olarak sıralı durduğundan, disk kafası ardışık okuma (sequential read) yaparak verileri çok hızlı çeker.

Non-Clustered Index (Kümelenmemiş İndeks)

Non-Clustered Index, tablodaki verilerin fiziksel sırasını değiştirmeyen, verilerden tamamen bağımsız ayrı bir disk alanında depolanan indeks türüdür. Bu yapı, kitabın arkasındaki fihrist tanımına birebir uyar. Bir tabloda birden fazla (veritabanı motoruna göre yüzlerce) Non-Clustered Index tanımlanabilir.

• Nasıl Çalışır?: Yaprak düğümlerde gerçek veri satırları yerine, o verinin disk üzerindeki fiziksel yerini gösteren bir işaretçi (Row Identifier - RID) veya tablo clustered indeksli ise Clustered Index anahtar değeri bulunur.

• Arama Süreci: SQL motoru önce Non-Clustered Index ağacında arama yapar, hedef yaprak düğümdeki işaretçiyi alır ve ardından gerçek veriyi okumak için tablonun kendisine gider. Bu ikinci adıma "Key Lookup" veya "RID Lookup" adı verilir.

• En Uygun Senaryolar: WHERE email = '[email protected]' gibi doğrudan spesifik bir satırı hedefleyen (point query) aramalar için idealdir.

Composite Index (Bileşik İndeks)

Birden fazla kolonun bir araya getirilerek tek bir indeks yapısı altında tanımlanmasıyla oluşan indekslere Composite Index (veya Multi-Column Index) denir. Özellikle karmaşık filtreleme, çoklu arama ve raporlama sorgularında kritik rol oynar.

• Sütun Sıralaması (Left-to-Right Rule): Composite indekslerde kolonların tanımlanma sırası hayati önem taşır. Örneğin CREATE INDEX idx_user ON users (country, city, age) şeklinde bir indeks tanımlandığında, bu indeks en soldaki kolondan başlayarak sıralanır.

• Kullanım Durumları: Sorguda country ve city filtrelenirse indeks aktif olarak kullanılır. Ancak sadece city veya sadece age filtrelenirse, en soldaki country kolonu sorguda yer almadığı için bu indeks Optimizer tarafından kullanılamaz.

• Avantajı: Doğru kolon sırasıyla tasarlanmış bir composite index, birden fazla tekli indekse göre disk alanından tasarruf sağlar ve "Index Covering" (Sorgunun ihtiyaç duyduğu tüm verilerin doğrudan indeks üzerinden karşılanması, tablonun kendisine gidilmemesi) senaryolarını mümkün kılar.

---

İndekslemenin Gizli Maliyetleri: Neden Dikkatli Olunmalıdır?

Yazılım geliştirme ve veritabanı yönetiminde en yaygın yanılgılardan biri, sorguları hızlandırmak amacıyla her yavaş çalışan veya sık kullanılan kolona rastgele indeks eklemektir. "Ne kadar çok indeks, o kadar hızlı veritabanı" algısı tamamen yanlıştır ve kurumsal ölçekteki sistemlerde felakete yol açabilir. İndeksler bedava performans sağlayan sihirli değnekler değildir; her indeksin veritabanı motoruna getirdiği ciddi bir işlem, bellek ve depolama maliyeti vardır.

Bir tabloya indeks eklediğinizde, veritabanı motoru arka planda iki bağımsız veri yapısını eş zamanlı olarak yönetmek zorunda kalır: Gerçek verilerin saklandığı ana tablo (heap veya clustered tree) ve indeks bilgilerini tutan B-Tree ağacı. Tablodaki veriler üzerinde yapılan her değişiklik, bu iki yapının senkronize bir şekilde güncellenmesini gerektirir. Bu durum, veri yazma operasyonlarında gözle görülür bir yavaşlama ve ek donanım maliyeti olarak karşımıza çıkar.

Veri Yazma Operasyonlarındaki (Insert/Update/Delete) Yavaşlama | Ekstra Disk Alanı (Storage) Tüketimi

Yazma Performansındaki Düşüş (Write Penalty)

Veritabanlarında veri yazma işlemleri (INSERT, UPDATE, DELETE) doğrudan disk performansı ile ilişkilidir. Bir tabloya yeni bir satır eklendiğinde (INSERT), sadece veri sayfası yazılmaz; o tablo üzerinde tanımlı olan tüm Non-Clustered indekslerin B-Tree ağaçlarına da bu yeni verinin karşılığı eklenmek ve ağaç dengelenmek (rebalancing) zorundadır.

• INSERT Maliyeti: Yeni eklenen veri, B-Tree yapısındaki ilgili yaprak düğüme (leaf node) yerleştirilir. Eğer o yaprak düğümün bulunduğu disk sayfası doluysa, "Page Split" (Sayfa Bölünmesi) adı verilen işlem gerçekleşir. Veritabanı motoru sayfayı ikiye böler, verileri yeniden dağıtır ve üst düğümlerdeki işaretçileri günceller. Bu işlem, disk üzerinde yoğun rastgele yazma (random write) operasyonlarına yol açar.

• UPDATE Maliyeti: İndekslenmiş bir kolonun değeri güncellendiğinde (örneğin bir kullanıcının statüsü değiştiğinde), veritabanı motoru eski indeks kaydını silmek ve yeni değer için B-Tree üzerinde yeni bir kayıt oluşturmak zorundadır. Bu, tek bir güncelleme sorgusunun arkasında birden fazla yazma işleminin tetiklenmesi anlamına gelir.

• DELETE Maliyeti: Bir satır silindiğinde, bu satıra işaret eden tüm indeks düğümleri de taranarak temizlenmek zorundadır.

Özellikle saniyede binlerce yazma alan IoT sistemleri, finansal işlem loglama veya yüksek trafikli e-ticaret sepet işlemlerinde, gereksiz her indeks yazma throughput (saniyedeki işlem sayısı) limitlerini yarı yarıya düşürebilir.

Ekstra Disk Alanı (Storage) Tüketimi

İndeksler, ana tablodan bağımsız olarak disk üzerinde fiziksel alan kaplar. Büyük veri setlerinde, indeks boyutları bazen gerçek veritabanı boyutunu aşabilir.

• Gizli Bulut Maliyetleri: AWS EBS GP3 veya benzeri bulut depolama birimlerinde depolama boyutu arttıkça ödenen ücret katlanır. Ayrıca, yedekleme (backup) süreleri uzar ve yedeklerin kapladığı alan büyür.

• RAM (Buffer Pool) Tüketimi: Veritabanı motorunun indeksleri hızlı kullanabilmesi için bu indeks sayfalarını RAM'de (önbellek) tutması gerekir. Çok büyük indeksler, RAM'de gerçek verilerin tutulabileceği alanları işgal eder. Bu durum, veritabanının "Memory-Bound" (bellek darboğazı) yaşamasına neden olur.

---

Kurumsal Veritabanlarında Doğru İndeksleme Stratejileri (Best Practices)

Kurumsal ölçekli bir BT altyapısında veritabanı performansı, doğrudan iş sürekliliği ve müşteri memnuniyeti anlamına gelir. Finans, e-ticaret, lojistik veya SaaS sektörlerinde çalışan sistemlerde doğru indeksleme stratejilerini hayata geçirmek, yazılım mimarlarının ve veritabanı yöneticilerinin en önemli sorumluluklarındandır. Başarılı bir indeksleme stratejisi, "karanlıkta kurşun sıkmak" yerine tamamen verilere, sorgu izleme (profiling) araçlarına ve Query Optimizer'ın ürettiği execution plan çıktılarına dayanmalıdır.

İndeks yönetimini bir süreç olarak ele almak gerekir. Yazılım geliştirme döngüsünün (SDLC) tasarım aşamasında doğru indeksler planlanmalı, test ortamlarında yük testleri ile doğrulanmalı ve üretim (production) ortamında sürekli olarak izlenmelidir. Unutulmamalıdır ki, uygulamanın veri yapısı ve kullanıcıların arama alışkanlıkları zamanla değişir; bu nedenle indekslerin de düzenli olarak revize edilmesi, kullanılmayan atıl indekslerin temizlenmesi ve fragmante olmuş indekslerin rehabilite edilmesi zorunludur.

Hangi Sütunlara İndeks Uygulanmalıdır? | Hangi Durumlarda İndeksten Kaçınılmalıdır?

Hangi Sütunlara İndeks Uygulanmalıdır?

Doğru sütun seçimi, indekslemeden maksimum okuma performansı elde etmenin anahtarıdır. Aşağıdaki özelliklere sahip kolonlar indeksleme için birincil adaylardır:

1. Yüksek Seçiciliğe (High Cardinality) Sahip Sütunlar: Seçicilik, bir kolondaki benzersiz değerlerin toplam satır sayısına oranıdır. Örneğin, id, email, tc_kimlik_no veya uuid gibi alanlar son derece seçicidir. Bu alanlarda yapılan aramalar doğrudan tek bir kaydı hedeflediği için B-Tree yapısı mükemmel çalışır.

2. Yabancı Anahtarlar (Foreign Keys - FK): İlişkisel veritabanlarında tabloları birbirine bağlayan (JOIN operasyonlarında kullanılan) FK kolonları mutlaka indekslenmelidir. Örneğin, siparisler tablosundaki musteri_id kolonu indekslenmediğinde, siparişler ile müşterileri birleştiren her sorgu tam tablo taramasına yol açar.

3. WHERE Koşullarında Sıkça Kullanılan Sütunlar: Kullanıcıların sistem üzerinde en sık arama yaptığı filtreleme kriterleri (örneğin aktiflik tarihi, kategori kodu, ürün kodu vb.) indekslenmelidir.

4. Sıralama ve Gruplama Sütunları (ORDER BY ve GROUP BY): Sorgularda verilerin belirli bir sırayla getirilmesi istendiğinde, veritabanı motoru "Filesort" adı verilen ve RAM/Diski aşırı yoran bir sıralama işlemi yapar. Sıralanacak kolon üzerinde indeks varsa, veriler zaten B-Tree içinde sıralı durduğu için bu maliyetli işlem tamamen baypas edilir.

Hangi Durumlarda İndeksten Kaçınılmalıdır?

Gereksiz indeksleme yükünden kaçınmak için aşağıdaki senaryolarda indeks tanımlanmamalı veya mevcut indeksler kaldırılmalıdır:

1. Düşük Seçiciliğe (Low Cardinality) Sahip Sütunlar: Örneğin bir kullanıcının aktif veya pasif olduğunu belirten is_active (boolean) kolonu ya da cinsiyet kolonu. Bu kolonlarda sadece 2 veya 3 farklı değer bulunur. Query Optimizer, bu tür kolonlarda indeks kullanmanın diski doğrudan okumaktan daha maliyetli olduğuna karar verir ve indeksi pas geçer.

2. Sık Güncellenen (High-Write) Tablolar ve Sütunlar: Gerçek zamanlı borsa verileri, sensör logları veya kullanıcıların son görülme zamanları (last_seen_at) gibi saniyede yüzlerce kez güncellenen kolonlarda indeks kullanımı, yazma performansını durma noktasına getirebilir.

3. Çok Küçük Tablolar: Birkaç yüz veya birkaç bin satırdan oluşan parametre veya şehir listesi gibi tablolar. Bu tabloların tamamı zaten tek bir veri sayfasında (Page) durur ve hafızaya (RAM) alınmıştır. Veritabanının indeks ağacını araması, tüm tabloyu saniyeler içinde doğrudan okumasından daha uzun sürebilir.

4. Büyük Metin (BLOB, TEXT) Kolonları: Çok uzun açıklama yazıları veya dosya içeriklerinin saklandığı kolonlar indekslenmemelidir. Eğer uzun metinler içinde arama yapılması zorunluysa, standart B-Tree indeksleri yerine "Full-Text Search (FTS)" indeksleri veya Elasticsearch gibi harici arama motorları tercih edilmelidir.

---