Risposte:
Nel peggiore dei casi, in cui stai guardando un campo non indicizzato, l'utilizzo MIN()
richiede un singolo passaggio completo della tabella. Utilizzando SORT
e LIMIT
richiede un filesort. Se eseguito contro un tavolo di grandi dimensioni, ci sarebbe probabilmente una differenza significativa nelle prestazioni percepite. Come punto dati senza senso, ha MIN()
preso .36s mentre SORT
e LIMIT
.84s contro una tabella di 106.000 righe sul mio server di sviluppo.
Se, tuttavia, stai guardando una colonna indicizzata, la differenza è più difficile da notare (il punto dati senza significato è 0,00 s in entrambi i casi). Guardando l'output di spiegare, tuttavia, sembra che MIN()
sia in grado di estrarre semplicemente il valore più piccolo dall'indice (righe 'Seleziona tabelle ottimizzate' e 'NULL') mentre SORT
e LIMIT
deve ancora eseguire un attraversamento ordinato dell'indice (106.000 righe). L'effettivo impatto sulle prestazioni è probabilmente trascurabile.
Sembra che MIN()
sia la strada da percorrere: è più veloce nel peggiore dei casi, indistinguibile nel migliore dei casi, è l'SQL standard ed esprime più chiaramente il valore che stai cercando di ottenere. L'unico caso in cui sembra che l'uso di SORT
e LIMIT
sarebbe auspicabile sarebbe, come menzionato da mson , in cui stai scrivendo un'operazione generale che trova i valori N superiori o inferiori da colonne arbitrarie e non vale la pena scrivere l'operazione per casi speciali.
SELECT MIN(`field`)
FROM `tbl`;
Semplicemente perché è ANSI compatibile. Il limite 1 è specifico per MySql come TOP è per SQL Server.
Come hanno sottolineato mson e Sean McSomething , MIN è preferibile.
Un altro motivo per cui ORDER BY + LIMIT è utile è se si desidera ottenere il valore di una colonna diversa dalla colonna MIN.
Esempio:
SELECT some_other_field, field
FROM tbl
ORDER BY field
LIMIT 1
Penso che le risposte dipendono da quello che stai facendo.
Se hai una query 1 off e l'intento è semplice come specificato, è preferibile selezionare min (campo).
Tuttavia, è comune che questi tipi di requisiti cambino in: prendi i primi n risultati, prendi n-esimo risultato, ecc.
Non penso che sia un'idea troppo terribile da affidare al database scelto. Cambiare dbs non dovrebbe essere fatto alla leggera e devi rivedere il prezzo che paghi quando fai questa mossa.
Perché limitarti ora, per il dolore che potresti o non potresti provare in seguito?
Penso che sia positivo rimanere ANSI il più possibile, ma questa è solo una linea guida ...
Date prestazioni accettabili, userei il primo perché è semanticamente più vicino all'intento.
Se le prestazioni fossero un problema, (la maggior parte degli ottimizzatori moderni probabilmente ottimizzerà entrambi per lo stesso piano di query, anche se è necessario testare per verificarlo), allora ovviamente utilizzerei quello più veloce.