Konuyu Açan
#1
Bir listede ilk sayfalar hızlıyken 20. sayfadan sonra sorguların belirgin biçimde ağırlaşması tanıdık mı? MySQL’de büyük tablolarla çalışırken OFFSET’in maliyeti can sıkabiliyor: veritabanı atlanacak satırları da bulup geçmek zorunda kalıyor.
Keyset pagination’da son görülen kaydın sırasını kullanarak devam ediyorsun. Örneğin tarih sırasına göre liste için:
Burada id’yi ikinci sıralama ölçütü yapmak önemli; created_at aynı olan kayıtlar varsa sayfalar arasında kaybolma ya da tekrarlanma riskini azaltıyor. Bu kullanım için created_at ve id’yi kapsayan uygun bir indeks de sorgunun işini kolaylaştırabilir.
Karşılığında, “doğrudan 47. sayfaya git” gibi bir gezinme daha zor hale geliyor. Akış, arama sonuçları veya sonsuz kaydırma için iyi çalışırken klasik sayfa numaralarında OFFSET daha pratik olabilir. Ayrıca listeye yeni kayıtlar eklenirken sayfa tutarlılığını nasıl ele aldığın da tasarıma bağlı.
Siz büyük listelerde hangi yaklaşımı kullanıyorsunuz? Keyset’e geçince beklemediğiniz bir köşe durumuyla karşılaştınız mı?
Keyset pagination’da son görülen kaydın sırasını kullanarak devam ediyorsun. Örneğin tarih sırasına göre liste için:
KOD
123456
SELECT id, created_at, title
FROM posts
WHERE (created_at, id) < (?, ?)
ORDER BY created_at DESC, id DESC
LIMIT 30;
Burada id’yi ikinci sıralama ölçütü yapmak önemli; created_at aynı olan kayıtlar varsa sayfalar arasında kaybolma ya da tekrarlanma riskini azaltıyor. Bu kullanım için created_at ve id’yi kapsayan uygun bir indeks de sorgunun işini kolaylaştırabilir.
Karşılığında, “doğrudan 47. sayfaya git” gibi bir gezinme daha zor hale geliyor. Akış, arama sonuçları veya sonsuz kaydırma için iyi çalışırken klasik sayfa numaralarında OFFSET daha pratik olabilir. Ayrıca listeye yeni kayıtlar eklenirken sayfa tutarlılığını nasıl ele aldığın da tasarıma bağlı.
Siz büyük listelerde hangi yaklaşımı kullanıyorsunuz? Keyset’e geçince beklemediğiniz bir köşe durumuyla karşılaştınız mı?