MIN / MAX vs ORDER BY dan LIMIT


101

Dari pertanyaan berikut, metode manakah yang menurut Anda lebih baik? Apa alasan Anda (efisiensi kode, kemudahan perawatan yang lebih baik, lebih sedikit WTFery) ...

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

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

Jawaban:


129

Dalam kasus terburuk, saat Anda melihat bidang yang tidak terindeks, penggunaan MIN()memerlukan satu jalur penuh tabel. Menggunakan SORTdan LIMITmembutuhkan fileort. Jika dijalankan dengan tabel besar, kemungkinan akan ada perbedaan signifikan dalam kinerja yang dipersepsi. Sebagai titik data yang tidak berarti, MIN()mengambil .36s sementara SORTdan LIMITmengambil .84s melawan tabel baris 106.000 di server dev saya.

Namun, jika Anda melihat kolom yang diindeks, perbedaannya lebih sulit untuk diperhatikan (poin data yang tidak berarti adalah 0,00 dalam kedua kasus). Melihat output dari menjelaskan, bagaimanapun, sepertinya MIN()dapat dengan mudah memetik nilai terkecil dari indeks (baris 'Pilih tabel yang dioptimalkan' dan 'NULL') sedangkan SORTdan LIMITmasih perlu melakukan traversal indeks (106.000 baris). Dampak kinerja sebenarnya mungkin dapat diabaikan.

Sepertinya MIN()begitulah cara untuk pergi - lebih cepat dalam kasus terburuk, tidak dapat dibedakan dalam kasus terbaik, adalah SQL standar dan paling jelas mengekspresikan nilai yang Anda coba dapatkan. Satu-satunya kasus di mana tampaknya menggunakan SORTdan LIMITakan diinginkan adalah, seperti yang disebutkan mson , di mana Anda menulis operasi umum yang menemukan nilai N atas atau bawah dari kolom arbitrer dan tidak ada gunanya menulis operasi kasus khusus.


7
o (n) untuk satu lulus tunggal vs 0 (nlogn) untuk penyortiran
Abhishek Iyer

1
@AbhishekIyer Anda benar, tapi saya akan menambahkan "dalam kasus terburuk untuk bidang yang tidak terindeks".
dmikam

Bagian tentang kasus terburuk yang tidak terindeks itu salah. Anda selalu membutuhkan pemindaian penuh, bagaimana lagi Anda tahu itu minimal atau maksimal? Ini tidak seperti Anda memindai dan nilainya berteriak: "Hei, akhirnya Anda menemukan saya! Saya Jack, maks!".
Robo Robok

Dalam pengujian dengan tabel terindeks dengan 470 juta baris, kedua kueri membutuhkan 0,00 detik. Namun, jika kita menambahkan ke kueri filter "WHERE field2 = x", kueri dengan LIMIT masih membutuhkan 0,00 detik dan kueri dengan MIN membutuhkan 0,21 detik.
Antonio Cañas Vargas

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

Hanya karena itu kompatibel dengan ANSI. Batas 1 khusus untuk MySql karena TOP untuk SQL Server.


Sebagian besar DBMS memiliki batas / offset atau setara, dan ini digunakan di sebagian besar aplikasi yang pernah saya kerjakan (bukan sebagai alternatif untuk MIN, tetapi untuk tujuan lain seperti pagination.)
finnw

@ Finnw - Saya setuju, tetapi contoh penanya adalah membandingkan batas dengan min secara eksplisit.
Otávio Décio

9

Seperti yang ditunjukkan oleh mson dan Sean McSomething , MIN lebih disukai.

Satu alasan lain di mana ORDER BY + LIMIT berguna adalah jika Anda ingin mendapatkan nilai kolom yang berbeda dari kolom MIN.

Contoh:

SELECT some_other_field, field
FROM tbl
ORDER BY field
LIMIT 1

4

Saya pikir jawabannya tergantung pada apa yang Anda lakukan.

Jika Anda memiliki kueri 1 kali dan maksudnya sesederhana yang Anda tentukan, pilih min (bidang) lebih disukai.

Namun, biasanya jenis persyaratan ini berubah menjadi - ambil n hasil teratas, ambil hasil nth - bln, dll.

Saya tidak berpikir itu ide yang terlalu buruk untuk berkomitmen pada database pilihan Anda. Mengubah dbs tidak boleh dilakukan dengan mudah dan harus merevisi harga yang Anda bayarkan saat Anda melakukan langkah ini.

Mengapa membatasi diri Anda sekarang, untuk rasa sakit yang mungkin Anda rasakan atau tidak rasakan di kemudian hari?

Saya pikir itu baik untuk tetap ANSI sebanyak mungkin, tapi itu hanya pedoman ...


3

Dengan kinerja yang dapat diterima, saya akan menggunakan yang pertama karena secara semantik mendekati maksudnya.
Jika kinerja menjadi masalah, (Sebagian besar pengoptimal modern mungkin akan mengoptimalkan keduanya ke rencana kueri yang sama, meskipun Anda harus menguji untuk memverifikasi itu) maka tentu saja saya akan menggunakan yang lebih cepat.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.