Konuyu Açan
#1
Liste ekranlarında başta her şey hızlıyken sayfa numarası büyüdükçe sorguların ağırlaştığını yaşayan var mı? MySQL’de büyük OFFSET değerlerinde veritabanı, döndürülecek satırlardan önce atlanacak kayıtları da taramak zorunda kalabiliyor. Bu yüzden özellikle kronolojik akışlarda keyset pagination iyi bir alternatif olabilir.
Örneğin kayıtları tarih ve ID’ye göre sıralıyorsak, yalnızca
Buna uygun olarak
Keyset’in bir bedeli de var: “37. sayfaya git” gibi rastgele sayfa atlamaları doğal olarak zorlaşıyor. Buna karşılık ileri-geri gezinme ve sürekli eklenen kayıtların bulunduğu akışlarda daha kullanışlı olabiliyor.
Siz gerçek projelerde hangi noktada OFFSET’i bırakıyorsunuz? Sıralama alanları değişebilen listelerde imleci nasıl tasarlıyorsunuz?
Örneğin kayıtları tarih ve ID’ye göre sıralıyorsak, yalnızca
created_at kullanmak yeterince güvenli değil; aynı zaman damgasına sahip kayıtlar sıralamada belirsizlik yaratabilir. Benzersiz bir ikinci sıralama alanı ekleyip son görülen kaydı imleç olarak kullanabiliriz:KOD
12345SELECT id, created_at, title
FROM posts
WHERE (created_at, id) < (:last_created_at, :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 30;Buna uygun olarak
(created_at, id) bileşik indeksi de değerlendirilir. Sorguda ayrıca status = 'published' gibi bir filtre varsa indeks sırasını filtre ve sıralama ihtiyacına göre test etmek gerekir; her sorguda aynı indeks en iyi sonucu vermeyebilir.Keyset’in bir bedeli de var: “37. sayfaya git” gibi rastgele sayfa atlamaları doğal olarak zorlaşıyor. Buna karşılık ileri-geri gezinme ve sürekli eklenen kayıtların bulunduğu akışlarda daha kullanışlı olabiliyor.
Siz gerçek projelerde hangi noktada OFFSET’i bırakıyorsunuz? Sıralama alanları değişebilen listelerde imleci nasıl tasarlıyorsunuz?