"SQL İpuçları" MyBatis milyon limit sayfalama optimizasyonu, performans minimum 6 kat artırıldı
Önsöz
Sayfalama sorgusu, gerçek geliştirmede en sık kullanılan senaryolardan biridir, ancak aynı zamanda genellikle en sorunlu yerdir. DBA meslektaşları tarafından verilen çözüm, "dizin / bileşik dizin" eklemek, örneğin ad, oluşturma_ zamanı, durum vb. Alanlara bir bileşik dizin eklemek, böylece dizinin bu koşullara göre sorgulama yapılırken etkili bir şekilde kullanılabilmesi ve performansın hızla iyileştirilmesidir. .
Yukarıdaki yaklaşım doğrudur 0,10 tablo sınırından * seçin Bu sorun değil, ama ne zaman limit 1000000,10 Veri okuma çok yavaş olduğunda. Yalnızca 10 parça veri istiyorum, ancak her sorgu 1 milyondan fazla satırı tarıyor ve bu yüksek frekanslı erişim tarafından engelleniyor. Peki bu sorunu çözmenin herhangi bir yolu var mı?
1. Seçenek - Maksimum Kimlik
Ön koşul: Veritabanı birincil anahtar kimliği kendi kendine artıyor
Normal sayfalama SQL ifadesi:
kullanıcılardan id, ad, içerik, create_time seçin id asc limit 1000000,10Optimize edilmiş SQL ifadesi şöyledir:
id'nin bulunduğu kullanıcılardan id, isim, içerik, create_time seçin > İd asc sınırı 10'a göre 1000000 siparişBunu görünce herkes anlamalı, değil mi? Sorgu yaparken, önceki sayfanın maksimum kimliğini sorgu koşulu olarak bir parametre olarak kullanabilirsiniz, bu nedenle mevcut sorgunun maksimum kimlikten başlayarak yalnızca 20 satırlık veriyi taraması gerekir.
Seçenek 2 - Depolama süresi
Sonra bazı öğrenciler, tasarlanan tablonun birincil anahtarı otomatik olarak artırılmazsa ne yapmam gerektiğini soracaklar. Verilerin saklama süresine dayanan başka bir yöntem vardır, spesifik yöntem yukarıdakiyle aynıdır.
id'nin bulunduğu kullanıcılardan id, isim, içerik, create_time seçin > '2020-01-0112:29:23' id asc limitine göre sıralama 10Bu şekilde, sorgu süresi temelde sabitlenir ve veri miktarı büyüdükçe değişmez.
Değerlendirme
Aşağıdaki şekilde görüldüğü gibi editör 300w + data hazırlamıştır.Bu tabloda 28 adet alan bulunmaktadır.
Normal sayfalama için gereken süre:
200w'den 10 parça veri elde etmek 12 saniyeden fazla sürdü.
Saklama süresine göre sayfalama:
Buradaki sorgu süresi, yukarıdaki SQL sorgusunun sonucunun yaratma zamanıdır, 2 saniyeden fazla sürdüğü görülebilmektedir. Performans yaklaşık 6 kat arttı!
Not: create_time alanına hiçbir dizin eklenmez.
sonuç olarak
Bir veritabanı tablosu çok büyük olduğunda ve LIMIT ofset ve uzunluktaki offset değeri çok büyük olduğunda, SQL sorgu ifadesi çok yavaş olacaktır, sıralamayı şu kadar artırmanız gerekir ve alana göre sıralamanın indekslenmesi gerekir. LIMIT'i optimize etmek için bir alt sorgu kullanırsanız, alt sorgu sürekli olmalıdır.Bir anlamda, alt sorgu nerede koşuluna sahip olmamalıdır.Verileri nerede filtreleyecek ve verilerin sürekliliğini kaybetmesine neden olacaktır. Sorguladığınız kayıt göreceli olarak büyükse ve veri aktarım miktarı görece büyükse, örneğin bir metin türü alanı içeriyorsa, bir alt sorgu oluşturabilirsiniz.
ID IN NEREDE öğelerden id, başlık, içerik SEÇİN (id limitine göre SİPARİŞ öğelerinden SEÇ ID sınırı 900000, 10);Limit ifadesinin ofseti büyükse, pk anahtar değerini ileterek offset = 0 değerini azaltabilirsiniz. Birincil anahtar tercihen int type ve auto_increment
SEÇİN * kullanıcılardan NEREDE uid > 456891 UID LİMİTİNE GÖRE SİPARİŞ 0, 10;Bu cümlenin genel fikri şu şekildedir:
SEÇİN * kullanıcılardan NEREDE uid > = (Kullanıcı SİPARİŞİNE GÖRE kullanıcı kimliğini seçin 895682, 1) limit 0, 10; Limitin ofset değeri çok büyükse, sayfaları çevirirken kullanıcı yorulur. Maksimum bir ofset ayarlayabilirsiniz. Eğer ofset aşılırsa, ayrı olarak işlenebilir, genellikle sürekli Sayfa çevirme çok büyükse ve kullanıcı deneyimi zayıfsa, kullanıcıya daha iyi bir kullanıcı deneyimi sağlanmalıdır.
