MIN / MAX - ORDER BY ve LIMIT


104

Aşağıdaki sorgulardan hangisinin daha iyi olduğunu düşünürdünüz? Nedenleriniz nelerdir (kod verimliliği, daha iyi bakım kolaylığı, daha az WTFery) ...

SELECT MIN(`field`)
FROM `tbl`;

SELECT `field`
FROM `tbl`
ORDER BY `field`
LIMIT 1;

Yanıtlar:


130

En kötü durumda, dizine eklenmemiş bir alana baktığınızda, kullanmak MIN()tablonun tek bir tam geçişini gerektirir. Bir dosya sıralaması kullanmak SORTve LIMITgerektirir. Büyük bir masaya karşı çalıştırılırsa, algılanan performansta büyük olasılıkla önemli bir fark olacaktır. Anlamsız bir veri noktası olarak, MIN()süre .36s aldı SORTve LIMITbenim dev sunucusunda bir 106.000 satır tabloya karşı .84s aldı.

Bununla birlikte, dizine alınmış bir sütuna bakıyorsanız, farkı fark etmek daha zordur (her iki durumda da anlamsız veri noktası 0,00'dür). Bununla birlikte, açıklamanın çıktısına bakıldığında MIN(), dizinden en küçük değeri ('Optimize edilmiş tabloları seçin' ve 'NULL' satırları) alabiliyor gibi görünüyor , oysa SORTve LIMIThala dizinin sıralı bir geçişini yapması gerekiyor. (106.000 satır). Gerçek performans etkisi muhtemelen ihmal edilebilir düzeydedir.

Görünüşe göre MIN()gitmenin yolu - en kötü durumda daha hızlı, en iyi durumda ayırt edilemez, standart SQL ve en açık şekilde elde etmeye çalıştığınız değeri ifade ediyor. Kullanmanın SORTve LIMITarzu edilir göründüğü tek durum , mson'un da bahsettiği gibi, keyfi sütunlardan üst veya alt N değerlerini bulan genel bir işlem yazdığınız ve özel durum işlemini yazmaya değmediği durumdur.


7
o (n) tek geçiş için - sıralama için 0 (nlogn)
Abhishek Iyer

1
@AbhishekIyer, tamamen haklısınız, ancak "indekslenmemiş alan için en kötü durumda" ekleyeceğim.
dmikam

Dizine alınmamış en kötü durumla ilgili bu kısım yanlış. Her zaman tam bir taramaya ihtiyacınız var, bunun minimum veya maksimum olduğunu başka nasıl anlarsınız? Taradığın gibi değil ve değer haykırıyor: "Hey, sonunda beni buldun! Ben Jack, en fazla!".
Robo Robok

470 milyon satırlık dizine alınmış bir tabloya sahip bir testte, her iki sorgu da 0,00 saniye sürer. Bununla birlikte, sorgulara bir "WHERE alan2 = x" filtresi eklersek, LIMIT olan sorgu hala 0,00 sn ve MIN içeren sorgu 0,21 sn sürmektedir.
Antonio Cañas Vargas

13
SELECT MIN(`field`)
FROM `tbl`;

Basitçe ANSI uyumlu olduğu için. TOP SQL Server için olduğu için Limit 1 MySql için özeldir.


Çoğu DBMS'de limit / offset veya eşdeğeri vardır ve üzerinde çalıştığım uygulamaların çoğunda kullanılıyor (
MIN'a

@finnw - Katılıyorum, ancak sorucunun örneği limit ile min'i açıkça karşılaştırıyordu.
Otávio Décio

10

As mson ve Sean McSomething sivri sahip çıkarak, MİN tercih edilir.

ORDER BY + LIMIT kullanmanın bir diğer nedeni de MIN sütunundan farklı bir sütunun değerini almak istemenizdir.

Misal:

SELECT some_other_field, field
FROM tbl
ORDER BY field
LIMIT 1

4

Sanırım cevaplar ne yaptığınıza bağlı.

1 kapalı sorgunuz varsa ve amaç belirttiğiniz kadar basitse, minimum (alan) seçimi tercih edilir.

Ancak, bu tür gereksinimlerin en iyi sonuçları al, sonuçları al, vb. Şeklinde değişmesi yaygındır.

Seçtiğiniz veritabanına bağlanmanın çok kötü bir fikir olduğunu sanmıyorum. Dbs değiştirmek hafife alınmamalı ve bu hamleyi yaptığınızda ödeyeceğiniz bedel revize etmek zorunda.

Daha sonra hissedebileceğiniz veya hissetmeyeceğiniz ağrı için neden şimdi kendinizi sınırlayasınız?

Mümkün olduğunca ANSI olarak kalmanın iyi olduğunu düşünüyorum, ancak bu sadece bir kılavuz ...


3

Kabul edilebilir performans verildiğinde, ilkini kullanırdım çünkü anlamsal olarak amaca daha yakın.
Performans bir sorun olsaydı, (Çoğu modern eniyileyici muhtemelen her ikisini de aynı sorgu planına göre optimize eder, ancak bunu doğrulamak için test etmeniz gerekir) o zaman elbette daha hızlı olanı kullanırdım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.