Yönetici panelleri için indeksleme: kullanıcıların en çok tıkladığı filtreleri—durum, atanan kişi, tarih aralıkları ve metin araması—gerçek sorgu modellerine göre optimize edin.
Yönetici panelleri genellikle ilk başta hızlı hisseder. Bir listeyi açar, kaydırır, kaydı tıklar ve devam edersiniz. Yavaşlama, insanların gerçek şekilde filtrelediği zaman ortaya çıkar: "Sadece açık biletler", "Maya'ya atanmış", "Geçen hafta oluşturulan", "Sipariş ID'si 1047 içeriyor". Her tıklama bir bekleme başlatır ve liste yapışkan olmaya başlar.
Aynı tablo bir filtre için hızlı, diğer bir filtre içinse acı verici derecede yavaş olabilir. Bir status filtresi küçük bir satır dilimini hedefleyip hızlı dönebilir. "İki tarih arasında oluşturulan" filtresi büyük bir aralığın okunmasını zorlayabilir. Bir atanan kişi (assignee) filtresi tek başına iyi çalışırken, durum ile sıralama birlikte kullanıldığında yavaşlayabilir.
İndeksler, veritabanının tüm tabloyu okumadan eşleşen satırları bulmak için kullandığı kestirme yoldur. Ancak indekslerin maliyeti vardır. Alan kaplarlar ve insert/update işlemlerini biraz yavaşlatırlar. Çok fazla indeks eklemek yazmaları yavaşlatabilir ve gerçek darboğazı çözmeyebilir.
Her şeyi indekslemek yerine, öncelik verin filtrelere ki bunlar:
Bu yazı kasıtlı olarak dar tutuyor. Yönetici listelerindeki ilk performans şikayetleri neredeyse her zaman aynı dört filtre türünden gelir: durum (status), atanan kişi (assignee), tarih aralıkları ve metin alanları. Bu davranışların neden farklı olduğunu anladığınızda, sonraki adımlar nettir: gerçek sorgu modellerine bakın, onlara en küçük uygun indeksi ekleyin ve yavaş yolu yeni problemler yaratmadan iyileştirdiğinizi doğrulayın.
Yönetici panelleri nadiren tek bir dev rapor yüzünden yavaşlar. Genelde gün boyu kullanılan birkaç ekran vardır ve bu ekranlar birçok küçük sorguyu tekrar tekrar çalıştırır.
Operasyon ekipleri çoğunlukla birkaç iş kuyruğunda yaşar: biletler, siparişler, kullanıcılar, onaylar, dahili istekler. Bu sayfalarda filtreler tekrar eder:
Veritabanının yaptığı iş niyete bağlıdır:
Yönetici panelleri ayrıca filtreleri tahmin edilebilir şekilde birleştirir: "Open + Unassigned", "Pending + Assigned to me" veya "Son 30 günde tamamlanan". İndeksler, sütun listesinden ziyade bu gerçek sorgu şekillerine uyduğunda en iyi çalışır.
Eğer AppMaster ile yönetici araçları inşa ediyorsanız, bu modeller genellikle en çok kullanılan liste ekranlarına ve varsayılan filtrelerine bakarak görünür. Bu, gerçek günlük işi sürükleyenleri indekslemeyi, kağıt üzerinde iyi görünenleri değil, kolaylaştırır.
İndekslemeyi triaj gibi düşünün. Filtre açılır kutusunda görünen her sütunun indekslenmesiyle başlamayın. Sürekli çalışan ve insanları en çok rahatsız eden birkaç sorguyla başlayın.
Hiç kimsenin kullanmadığı bir filtreyi optimize etmek boşa zaman kaybıdır. Gerçek sıcak yolları bulmak için sinyalleri birleştirin:
Birçok ekipte bu varsayılan görünüm "Open tickets" veya "New orders" gibidir. Her biri birine yenilendiğinde, sekme değiştirildiğinde veya yanıt verdikten sonra geri dönüldüğünde çalışır.
İndeks eklemeden önce, ortak sorgularınızı davranışlarına göre gruplayın. Çoğu yönetici liste sorgusu birkaç kovana düşer:
status = 'open', assignee_id = 42created_at iki tarih arasındaORDER BY created_at DESC ve sayfa 2'yi getirHer üst ekran için WHERE, ORDER BY ve sayfalandırmayı içerecek şekilde sorgu şeklini yazın. UI'de benzer görünen iki sorgu veritabanında çok farklı davranabilir.
Öncelikle bir öncelikli hedef seçin: ilk yüklenen varsayılan liste sorgusu. Sonra 2 veya 3 yüksek frekanslı sorgu daha seçin. Genelde bu, en büyük gecikmeleri azaltmak için yeterlidir ve veritabanınızı bir indeks müzesi haline getirmez.
Örnek: Bir destek ekibi, Tickets listesini status = 'open' filtresiyle, en yeniye göre sıralanmış ve isteğe bağlı atanan kişi ve tarih aralığı ile açıyor. Önce bu tam kombinasyonu optimize edin. Hızlı olunca, kullanım bazlı olarak bir sonraki ekrana geçin.
Durum, insanların ilk eklediği filtrelerden biridir ve doğru kullanılmazsa fayda sağlamayan indeksler oluşturmak kolaydır.
Çoğu status alanı düşük kardinalitelidir: sadece birkaç değer (open, pending, closed). Bir indeks en çok sonucu küçük bir dilime daraltabildiğinde yardımcı olur. Eğer satırların %80–95'i aynı durumda ise, tek başına status indeksi genellikle çok fazla değişiklik yapmaz. Veritabanı hâlâ büyük bir satır kümesini okumak zorunda kalır ve indeks ek yük getirir.
Genelde fayda şu durumlarda hissedilir:
Sık görülen bir desen "bana açık öğeleri göster, en yeni ilk." Bu durumda filtre ve sıralamayı birlikte indekslemek genelde status tek başına indekslemekten daha iyidir.
Erken fayda sağlayan kombinasyonlar:
status + updated_at (duruma göre filtrele, son değişikliklere göre sırala)status + assignee_id (iş kuyruğu görünümleri)status + updated_at + assignee_id (sadece bu tam görünüm yoğun kullanılıyorsa)Bir durum hâkimse kısmi (partial) indeksler iyi bir orta yol sağlar. Örneğin "open" ana görünümse, sadece open satırlarını indekslemek indeksi küçük tutar ve yazma maliyetini azaltır.
-- PostgreSQL example: index only open rows, optimized for newest-first lists
CREATE INDEX CONCURRENTLY tickets_open_updated_idx
ON tickets (updated_at DESC)
WHERE status = 'open';
Pratik bir test: yavaş yönetici sorgusunu durum filtresiyle ve filtresiz çalıştırın. Her iki durumda da yavaşsa, sadece status indeksi onu kurtarmaz. Önceliği sıralama ve listeyi gerçekten küçülten ikinci filtreye verin.
Çoğu yönetici panelinde atanan kişi (assignee) kayıtta saklanan bir kullanıcı ID'sidir: assignee_id gibi bir yabancı anahtar. Bu klasik bir eşitlik filtresidir ve basit bir indeksle sıkça hızlı bir kazanç sağlar.
Assignee genelde diğer filtrelerle birlikte de görünür çünkü insanların çalışma şekline uyar. Bir destek lideri "Alex'e atanmış" filtreleyip sonra "Open" ile daraltmak isteyebilir. Bu görünüm yavaşsa, çoğunlukla tek kolonlu indeks yeterli olmaz.
İyi bir başlangıç bileşik indeks, yaygın filtre kombinasyonunu eşleştiren şudur:
(assignee_id, status) için "benim açık öğelerim"(assignee_id, status, updated_at) eğer liste aynı zamanda son aktiviteye göre sıralanıyorsaBileşik indekslerde sıra önemlidir. Eşitlik filtrelerini öne koyun (çoğunlukla assignee_id, sonra status) ve sıralama veya aralık sütununu sona (updated_at) koyun. Bu veritabanının verimli kullanabileceği şekilde hizalanır.
Atanmamış (unassigned) öğeler sıkça sorun çıkarır. Birçok sistem "atanmamış"ı NULL olarak saklar ve yöneticiler için bu filtre sık kullanılır. NULL değerler veritabanı planını değiştirebilir; bu yüzden atanmış öğeler için çok iyi çalışan bir indeks, atanmamış için işe yaramayabilir.
Eğer atanmamış birinci-sınıf iş akışıysa, bir yaklaşım seçin ve test edin:
assignee_id nullable kalsın, ama WHERE assignee_id IS NULL sorgusunu test edin ve gerekiyorsa indeksleyin.AppMaster ile yönetici paneli inşa ediyorsanız, ekibinizin en çok hangi filtre ve sıralamaları kullandığını kaydetmek ve ardından bunları küçük bir seçilmiş indeks setiyle aynalamak faydalıdır.
Tarih filtreleri genelde "son 7 gün" veya "son 30 gün" gibi hızlı ön ayarlar ve ayrıca özel başlangıç-bitiş seçimleri ile görünür. Basit gözükürler ama büyük tablolarda çok farklı veritabanı işi tetikleyebilirler.
İlk olarak, insanların hangi zaman damgası sütununu kastettiği konusunda net olun. Kullan:
created_at için "yeni öğeler" görünümüupdated_at için "son değişenler" görünümüO sütuna normal bir btree indeksi koyun. Olmazsa her "son 30 gün" tıklaması tam tablo taramasına dönüşebilir.
Ön ayar aralıklar genelde created_at >= now() - interval '30 days' gibi görünür. Bu bir aralık koşuludur ve created_at indeksi verimli kullanılabilir. UI ayrıca en yenilerle sıralıyorsa, sıralama yönünü eşleştirmek (ör. PostgreSQL'de created_at DESC) yoğun kullanılan listelerde yardımcı olabilir.
Tarih aralıkları diğer filtrelerle birleştiğinde (status, assignee) seçici olun. Kombinasyon yoğun kullanılıyorsa bileşik indeksler çok iyi çalışır. Aksi halde yazma maliyetini artırıp çok az fayda sağlarlar.
Pratik kurallar:
(status, created_at) yardımcı olur.created_at indeksi tutun ve çok sayıda bileşik indeksten kaçının.Zaman dilimi ve sınırlar birçok "kayıp kayıt" hatasına yol açar. Kullanıcı tarihlerinde zaman yoksa bitiş tarihini nasıl yorumlayacağınıza karar verin. Güvenli bir desen kapsayıcı başlangıç ve dışlayıcı bitiştir: created_at >= start ve created_at < end_next_day. Zaman damgalarını UTC'de depolayın ve kullanıcı girişini sorgulama önce UTC'ye çevirin.
Örnek: bir yönetici 10 Ocak'tan 12 Ocak'a kadar seçim yapıp 12 Ocak'taki tüm öğeleri görmek istiyor. Eğer sorgunuz <= '2026-01-12 00:00' kullanıyorsa 12 Ocak'ın çoğunu düşürürsünüz. İndeks uygundur, ama sınır mantığı yanlıştır.
Metin arama, birçok yönetici panelinin yavaşlamasının temel nedenidir çünkü insanlar her şeyi bulmak için tek bir kutu bekler. İlk düzeltme, iki ihtiyacı ayırmaktır: kesin eşleşme (hızlı ve öngörülebilir) ve içerik araması (esnek ama ağır).
Kesin eşleşme alanları: sipariş ID'si, bilet numarası, e-posta, telefon, dış referans. Bunlar normal veritabanı indeksleri için idealdir. Yönetici sıkça bir ID veya e-posta yapıştırıyorsa, basit bir indeks ve eşitlik sorgusu anında hissettirir.
İçerik araması ise birinin bir parçacık yazıp "refund" veya "john" gibi isimleri adlarda, notlarda görmek istemesi durumudur. Bu genelde LIKE %term% olarak uygulanır. Öndeki wildcard normal B-tree indeksinin kullanılamamasına yol açtığı için veritabanı çok sayıda satırı tarar.
Aşağıdaki uygulama yollarını izleyin:
term%) için standart indeksler yardımcı olur ve genelde adlar için yeterince iyi hissedilir.LIKE %term%'i düzeltmesini beklemeyin.Girdi kuralları beklenenden daha çok işe yarar. Yükü azaltır ve sonuçları tutarlı kılar:
Küçük örnek: bir yönetici "ann" araması yaparsa ve sisteminiz LIKE %ann%'i notlar, adlar ve adresler üzerinde çalıştırıyorsa binlerce kaydı tarayabilir. Önce kesin alanları (e-posta veya müşteri ID'si) kontrol edip, sadece gerektiğinde daha akıllı bir metin indeksine düşerseniz arama hızlı kalır.
İndeksler eklemek kolaydır ama pişmanlık yaratmak da kolaydır. Güvenli bir iş akışı, yöneticilerin güvendiği filtrelere odaklanmanızı sağlar ve "belki işe yarar" indekslerin daha sonra yazmaları yavaşlatmasını önler.
Gerçek kullanımla başlayın. En iyi sorguları iki şekilde çıkarın:
Yönetici panelleri için bunlar genelde filtre ve sıralamaya sahip liste sayfalarıdır.
Sonra veritabanının gördüğü sorgu şeklini tam olarak yakalayın. Kesin WHERE ve ORDER BY'yi, sıralama yönünü ve yaygın kombinasyonları yazın (örneğin: status = 'open' AND assignee_id = 42 ORDER BY created_at DESC). Küçük farklar hangi indeksin yardımcı olacağını değiştirebilir.
Basit bir döngü kullanın:
Sayfalandırma ayrı bir kontrol gerektirir. Offset tabanlı sayfalandırma (OFFSET 20000) derinleştikçe yavaşlar, indeks olsa bile. Kullanıcılar çok derin sayfalara rutin olarak gidiyorsa cursor tarzı sayfalandırmayı düşünün ("bu zaman damgası/ID'den önceki öğeleri göster") böylece indeks büyük tablolarda tutarlı iş yapar.
Son olarak, indeks listenizin ayırt edilebilir kalması için küçük bir kayıt tutun: indeks adı, tablo, sütunlar (ve sıra) ve desteklediği sorgu.
İnsanların gerçek nasıl filtrelediğini, sıraladığını ve sayfalandırdığını kontrol etmeden indeks eklemek yönetici panelini yavaşlatmanın en hızlı yoludur. İndekslerin maliyeti vardır: alan ve her insert/update için ekstra iş.
Bu desenler çoğu problemi yaratır:
LIKE '%term%' gibi içerik aramasını düzelteceğini varsaymak.Sık görülen senaryo: destek ekibi biletleri Status = Open ile filtreleyip updated time'a göre sıralıyor ve sayfalar. Eğer sadece status üzerine indeks eklediyseniz, veritabanı hâlâ tüm açık biletleri toplayıp sıralamak zorunda kalabilir. Filtre ve sıralamayı birlikte eşleştiren bir indeks ilk sayfayı hızlı döndürebilir.
Yönetici UI değişikliklerinden önce ve sonra kısa bir gözden geçirme yapın:
WHERE + ORDER BY desenine uyan bir indeksi doğrulayın.LIKE '%term%') kontrol edin ve içerik aramasının gerçekten gerekli olup olmadığına karar verin.Eğer AppMaster üzerinde PostgreSQL kullanarak yönetici panelleri inşa ediyorsanız, bu gözden geçirmeyi yeni ekranları yayınlamanın parçası yapın. Doğru indeksler genelde UI'nin kullandığı filtre ve sıralamalardan doğar.
Daha fazla indeks eklemeden önce, elinizdeki indekslerin günlük kullanılan kesin filtrelere yardım ettiğinden emin olun. İyi bir yönetici paneli, sık kullanılan yollar üzerinde anında hissettirir, nadir tekil aramalarda değil.
Birkaç kontrol çoğu problemi yakalar:
WHERE hem ORDER BY'yi eşleştiren bir indeksi kullandığını doğrulayın, yalnızca bir parçayı değil.Pratik bir sonraki adım, altın yollarınızı düz cümlelerle yazmaktır: "Destek ajanları açık biletleri, bana atanmış, son 7 gün, en yeniye göre sıralı filtreliyor." Bu cümleleri kullanarak onları açıkça destekleyen küçük bir indeks seti tasarlayın.
Eğer hâlâ geliştirme aşamasındaysanız, çok fazla ekran oluşturmadan önce veri modelinizi ve varsayılan filtreleri modellemek yardımcı olur. AppMaster (appmaster.io) ile yönetici görünümlerini hızlıca yineleyebilir, gerçek kullanım sıcak yolları belli olduktan sonra yalnızca birkaç indeks ekleyebilirsiniz.
Yönetici panelinde önce neyi indekslemeliyim?Öncelikle sürekli çalışan sorgularla başlayın: yöneticinin ilk gördüğü varsayılan liste görünümü ve gün boyunca sıkça tıklanan 2–3 filtre. Sıklık ve sıkıntı düzeyini (en sık kullanılan ve en yavaş olanlar) ölçün, sonra yalnızca bu kesin sorgu şekillerindeki bekleme süresini bariz şekilde azaltan indeksleri ekleyin.
Aynı tabloda neden bir filtre hızlıyken diğeri çok yavaş?Farklı filtreler farklı miktarda iş yükü gerektirir. Bazı filtreler çok küçük bir satır kümesine daralırken, diğerleri büyük bir aralığı etkileyebilir veya büyük sonuç kümelerini sıralamayı gerektirebilir. Bu yüzden bir filtre indeksten iyi faydalanırken diğeri hala tarama ve sıralama yapabilir.
Bir status kolonuna her zaman indeks eklemeli miyim?status kolonuna her zaman indeks eklemeyin. Satırların çoğu aynı duruma sahipse, yalnızca status üzerine indeks koymak sıkı bir kazanç sağlamayabilir. İndeksin işe yaradığı durumlar: durum nadir olduğunda, durum başka bir koşulla birlikte sonuçları gerçekten küçültüyorsa veya durumu sıralama/diğer filtrelerle birlikte eşleştiren ortak bir görünüm varsa.
“Açık ögeler, en yeniler ilk” görünümünü nasıl hızlandırırım?İnsanların gerçekte yaptığı gibi filtreleme ve sıralamayı eşleştiren bileşik bir indeks kullanın. Örneğin, PostgreSQL'de tek bir durum hâkimse kısmi (partial) indeks küçük ve verimli bir çözüm olabilir; örnek: status = 'open' için sadece ilgili satırları indekslemek gibi.
Atanan kişiye göre filtrelemeyi en iyi nasıl indekslerim?Basit bir assignee_id indeksi genellikle hızlı bir kazanç sağlar çünkü eşitlik filtresidir. Eğer temel iş akışı “benim açık öğelerim” ise, önce assignee_id sonra status (ve gerekiyorsa sıralama sütunu) ile başlayan bileşik bir indeks tekil kolon indekslerinden daha iyi performans gösterir.
Neden “atanmamış” filtrelenince `assignee_id` indeksine rağmen yavaş kalıyor?Çoğu sistemde “atanmamış” değer NULL ile saklanır ve WHERE assignee_id IS NULL sorgusu WHERE assignee_id = 123 ile farklı davranabilir. Atanmamış kuyruğun önemli olduğu durumlarda bu sorguyu özellikle test edin ve gerekiyorsa kısmi indeks gibi bir strateji uygulayın.
“Son 7 gün” gibi tarih aralığı filtrelerini nasıl indekslemeliyim?İnsanların genelde filtrelediği zaman damgası sütununa (çoğunlukla created_at veya updated_at) normal bir btree indeksi koyun. Örneğin, created_at >= now() - interval '30 days' gibi bir aralık koşulunda created_at indeksi verimli şekilde kullanılabilir. Eğer UI ayrıca en yenilerle sıralıyorsa, sıralama yönünü eşleştirmek (ör. created_at DESC) yoğun kullanılan listelerde yardımcı olabilir.
Yönetici tarih filtrelerinde zaman dilimi ve bitiş-tarihi hatalarını nasıl önlerim?Çoğu eksik-kayıt hatası zaman dilimi ve sınırlarla ilgilidir. Güvenli bir yaklaşım kapsayıcı başlangıç ve dışlayıcı bitiş kullanmaktır: kullanıcı tarihlerinin UTC'ye dönüştürülmesi ve created_at >= start ve created_at < end_next_day ile sorgulanması, bitiş günündeki kayıtların yanlışlıkla düşürülmesini engeller.
Metin alanlarında “içerir” arama neden normal bir indeksle düzelmiyor?Çünkü LIKE %term% gibi içerik aramaları normal btree indeksleri kullanamaz; bu tür sorgular genelde çok sayıda satır tarar. ID, e-posta, sipariş numarası gibi kesin aramalar ilk sınıf yapın. Gerçek içerik araması gerekiyorsa PostgreSQL full-text search veya trigram indeksleri gibi uygun araçları kullanın.
Tüm filtrelenebilir sütunları indeksleyerek yavaşlamalardan kaçınabilir miyim?Çok fazla indeks eklemek depolama maliyetini artırır ve insert/update hızlarını düşürür; ayrıca doğru darboğazı yakalamazsanız yine yavaşlıklarla karşılaşırsınız. Tek seferde bir indeks değişikliği yapın, aynı yavaş sorguyla yeniden ölçün ve yalnızca hedef sorguyu bariz şekilde hızlandıran değişiklikleri tutun.
AppMaster ile yönetici ekranları oluşturuyorsanız, eklemeden önce ekranda kullanılan filtre ve sıralamaları kaydedip gerçek kullanımın ortaya çıkardığı sıcak yolları destekleyen küçük bir indeks seti eklemek daha güvenli bir yaklaşımdır.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
