In risposta a this SQL question, ho riscontrato una dichiarazione che l'operatore a valore fisso IN() è molto più lento di INNER JOIN con lo stesso contenuto, al punto che è meglio crea una tabella temporanea per i valori e UNISCI a loro. È vero (in generale, con MySQL, qualsiasi altro motore SQL) e se sì - perché? Intuitivamente, IN dovrebbe essere più veloce - stai confrontando la potenziale corrispondenza con un set fisso di valori, che sono già in memoria e nel formato necessario, mentre con JOIN dovresti consultare gli indici, caricare potenzialmente i dati dal disco e eseguire altre operazioni che potrebbero non essere necessarie con IN. Mi sto perdendo qualcosa di importante?Prestazioni SQL IN() vs. INTERNO performance
Nota che a differenza di this question e di molti duplicati, sto parlando di IN() con set di valori fisso, non di sottoquery.
Questo è sicuramente qualcosa che varia tra piattaforme DB. Nella mia esperienza con SQL Server e PostgreSQL, le clausole 'IN' sulle costanti rispetto agli indici sono molto veloci. – Pointy
La domanda a cui è collegato è SQL Server. Non so se sei già a conoscenza, ma MySQL può essere abbastanza catastrofico con [anche con una query secondaria] (http://stackoverflow.com/questions/3417074/why-would-an-in-condition-be-slower -than-in-sql/3417190 # 3417190) –
@Martin domanda originale (primo collegamento) riguardava MySQL. Conosco i problemi di MySQL con le sottoquery, ma ho pensato che vada bene con le liste costanti, ecco perché la richiesta nella risposta di @ DVK mi ha sorpreso. – StasM