Pagination Performansı Hakkında

Merhaba,

Milyonlarca veri kaydı tutan bir tablom mevcut. Hızlı pagination yapısı kullanabilmek adına bir soru sormak istiyorum.
Daha önce 2 milyona yakın bir tablomda LIMIT,OFFSET kullanımlarında yaşadığım sorunu çözmek için pek çok yardım aldım.
İlk 300,500 bin veriye kadar 15 veri getir dediğimizde sorgu süresi 0.500 altında.

Fakat OFFSET son kayıtlara doğru gidince LIMIT 15 dahi olsa sorgu sürem 1.7 saniyelere kadar ulaşabiliyor. Sonuçta milyonlarca kayıt verinin bulunduğu tabloda en sonlara doğru tarama yapmaya başlıyor.

OFFSET kullanımı yerine id > xxx and id < xxx gibi yapı kullanınca aynı pagination mantığında 15 veriyi hangi offset olursa olsun 0.0080 saniyede getiriyor.
Tabi bu kullanımı yapınca bana gelen cevaplar genelde direk tablodan bir veri silinirse veya id değeri olurda güncellenir arada boşluk oluşursa sapıtıyor deniliyor.
Bu işlemlerin yapıldığı tablo odeme_kayitlari tablosu. Bu tablodan asla veri silinemiyor zaten silinmemesi de gerekiyor.
PHPMyAdmin üzerinden delete yapmaya çalıştığımızda trigger devreye girip silemezsin uyarısı veriyor. Aynı şekilde id değeri güncellenmeye kalkarsa onada id değerini güncelleyemezsin uyarısı veriyor.

Bu şartlar altında milyonlarca verinin bulunduğu bu tabloda offset yerine id > xx olayını kullanmanın bir sakıncası var mı?

id olayı saçmalık, onun yerine indexleri kullanarak performansı arttırabilirsiniz.

ekstra olarak sadece gerekli olan verileri isteyin, select * yapmak yerine select id, isim vs. şeklinde alın bu da etkileyecektir

index kullanılsa bile veri 10+milyon gibi değerlere ulaşınca süre çok çok uzamaya başlıyor.
Tablo yapısı, ilişkilendirmesi hepsi gayet başarılı. Neredeyse 1 Byte hesabı bile yapılmış durumda.

ID olayı saçmalık dediniz hocam ama tam olarak neden sebep öyle dediniz? Pagination mantığı sorunsuz çalışıyor ve 0.0080 gibi sürelerde getiriyor sonuçları.

veri silindiğinde vs sorun yaşayacaksınız, id ile çalışmak istiyorsanız örneğin sayfa başı 10 içeriğiniz olsun siz bu 10 içeriğinde silinmeyeceğini biliyorsunuz ama alttan silinen 20 içerik bütün sayfaları kaydıracak. onun için mesela ilk 100 sayfa için 10 lu düşündüğünüzde 1000 kayıt eder siz bunu 100 ile çarpıp orada bir swich yapısından geçirip mesela o limtilerin arasını kontrol edebilirsiniz. yani 10 milyon varsa siz bunu 100 parçaya ayırdığınızda sorgu sayınız azalır ve id sıralamsına göre daha uzun güven sağlayan bir çözüm olmuş olur. bu şekilde 100.000 içerik silinmediği sürece sayfalar kaymayacaktır.

Örnek şöyle olacak mesela 78. sayfa ilk 1000 de oludğundan 1000 x 100 = 100.000
SELECT (istenilenler) from (tablo) WHERE id > 0 AND id < 100.000 ORDER BY id DESC LIMIT 780, 10

Konuda belirttiğim gibi ama şöyle bir durum var.
Bu tablo ödemelerin tutulduğu tablo olduğu için.

Asla ve asla veri silinmiyor. ID değerleri asla güncellenemiyor. Yani silinme diye bir olay yok.
Manuel silmeye kalksanız bile TRIGGER tanımlı. Silme işlemini durduruyor,engelliyor.

Ben bundan sebep ID mantığı ile pagination olayını kullandım. Bu şartlar altında çok hızlı çalıştığı için uygun mu diye sormak istedim hocam. Yoksa sizin dediğiniz doğru ID olayı tamamen saçmalık. Fakat bizim tablomuzda asla veri silinmiyor.

oraya dikkat etmemişim, silinmiyorsa sıkıntı yok rahatça kullanabilirsiniz