Prestazioni dell'operatore MySQL "IN" su un numero (elevato?) Di valori

Ultimamente ho sperimentato Redis e MongoDB e sembrerebbe che ci siano spesso casi in cui si memorizza un array di ID in MongoDB o Redis. Continuerò con Redis per questa domanda poiché chiedo dell'operatore MySQL IN .

Mi chiedevo quanto sia efficiente elencare un numero elevato (300-3000) di ID all'interno dell'operatore IN, che sarebbe simile a questo:

SELECT id, name, price
FROM products
WHERE id IN (1, 2, 3, 4, ...... 3000)

Immagina qualcosa di semplice come una tabella di prodotti e categorie a cui potresti normalmente UNIRE insieme per ottenere i prodotti da una determinata categoria . Nell'esempio sopra puoi vedere che sotto una data categoria in Redis ( category:4:product_ids) restituisco tutti gli ID prodotto dalla categoria con id 4 e li inserisco nella SELECTquery sopra all'interno INdell'operatore.

Quanto è performante?

È una situazione "dipende"? O c'è un concreto "questo è (non) accettabile" o "veloce" o "lento" o dovrei aggiungere un LIMIT 25, o non aiuta?

SELECT id, name, price
FROM products
WHERE id IN (1, 2, 3, 4, ...... 3000)
LIMIT 25

O dovrei tagliare l'array di ID prodotto restituito da Redis per limitarlo a 25 e aggiungere solo 25 ID alla query anziché 3000 e aggiungerlo LIMITa 25 dall'interno della query?

SELECT id, name, price
FROM products
WHERE id IN (1, 2, 3, 4, ...... 25)

Eventuali suggerimenti / feedback sono molto apprezzati!

In generale, se l' INelenco diventa troppo grande (per un valore mal definito di 'troppo grande' che di solito è nella regione di 100 o inferiore), diventa più efficiente usare un join, creando una tabella temporanea se necessario per tenere i numeri.

Se i numeri sono un insieme denso (senza spazi vuoti, come suggeriscono i dati di esempio), puoi fare ancora meglio con WHERE id BETWEEN 300 AND 3000.

Tuttavia, presumibilmente ci sono delle lacune nell'insieme, a quel punto potrebbe essere meglio andare con l'elenco dei valori validi dopotutto (a meno che gli spazi siano relativamente pochi in numero, nel qual caso potresti usare:

WHERE id BETWEEN 300 AND 3000 AND id NOT BETWEEN 742 AND 836

O qualunque siano le lacune.

Ho fatto alcuni test e, come dice David Fells nella sua risposta , è abbastanza ben ottimizzato. Come riferimento, ho creato una tabella InnoDB con 1.000.000 di registri e facendo una selezione con l'operatore "IN" con 500.000 numeri casuali, ci vogliono solo 2,5 secondi sul mio MAC; la selezione dei soli registri pari richiede 0,5 secondi.

L'unico problema che ho avuto è che ho dovuto aumentare il max_allowed_packetparametro dal my.cnffile. In caso contrario, viene generato un misterioso errore "MYSQL è andato via".

Ecco il codice PHP che utilizzo per fare il test:

$NROWS =1000000;
$SELECTED = 50;
$NROWSINSERT =15000;

$dsn="mysql:host=localhost;port=8889;dbname=testschema";
$pdo = new PDO($dsn, "root", "root");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$pdo->exec("drop table if exists `uniclau`.`testtable`");
$pdo->exec("CREATE  TABLE `testtable` (
        `id` INT NOT NULL ,
        `text` VARCHAR(45) NULL ,
        PRIMARY KEY (`id`) )");

$before = microtime(true);

$Values='';
$SelValues='(';
$c=0;
for ($i=0; $i<$NROWS; $i++) {
    $r = rand(0,99);
    if ($c>0) $Values .= ",";
    $Values .= "( $i , 'This is value $i and r= $r')";
    if ($r<$SELECTED) {
        if ($SelValues!="(") $SelValues .= ",";
        $SelValues .= $i;
    }
    $c++;

    if (($c==100)||(($i==$NROWS-1)&&($c>0))) {
        $pdo->exec("INSERT INTO `testtable` VALUES $Values");
        $Values = "";
        $c=0;
    }
}
$SelValues .=')';
echo "<br>";


$after = microtime(true);
echo "Insert execution time =" . ($after-$before) . "s<br>";

$before = microtime(true);  
$sql = "SELECT count(*) FROM `testtable` WHERE id IN $SelValues";
$result = $pdo->prepare($sql);  
$after = microtime(true);
echo "Prepare execution time =" . ($after-$before) . "s<br>";

$before = microtime(true);

$result->execute();
$c = $result->fetchColumn();

$after = microtime(true);
echo "Random selection = $c Time execution time =" . ($after-$before) . "s<br>";



$before = microtime(true);

$sql = "SELECT count(*) FROM `testtable` WHERE id %2 = 1";
$result = $pdo->prepare($sql);
$result->execute();
$c = $result->fetchColumn();

$after = microtime(true);
echo "Pairs = $c Exdcution time=" . ($after-$before) . "s<br>";

E i risultati:

Insert execution time =35.2927210331s
Prepare execution time =0.0161771774292s
Random selection = 499102 Time execution time =2.40285992622s
Pairs = 500000 Exdcution time=0.465420007706s

È possibile creare una tabella temporanea in cui inserire un numero qualsiasi di ID ed eseguire query annidate Esempio:

CREATE [TEMPORARY] TABLE tmp_IDs (`ID` INT NOT NULL,PRIMARY KEY (`ID`));

e seleziona:

SELECT id, name, price
FROM products
WHERE id IN (SELECT ID FROM tmp_IDs);

L'utilizzo INcon un set di parametri di grandi dimensioni su un ampio elenco di record sarà infatti lento.

Nel caso che ho risolto di recente avevo due clausole where, una con 2,50 parametri e l'altra con 3.500 parametri, interrogando una tabella di 40 milioni di record.

La mia query ha richiesto 5 minuti utilizzando lo standard WHERE IN. Utilizzando invece una sottoquery per l' istruzione IN (inserendo i parametri nella propria tabella indicizzata), ho ridotto la query a DUE secondi.

Nella mia esperienza ho lavorato sia per MySQL che per Oracle.

INva bene e ben ottimizzato. Assicurati di usarlo su un campo indicizzato e stai bene.

È funzionalmente equivalente a:

(x = 1 OR x = 2 OR x = 3 ... OR x = 99)

Per quanto riguarda il motore DB.

Quando si forniscono molti valori per l' INoperatore, è necessario innanzitutto ordinarlo per rimuovere i duplicati. Almeno lo sospetto. Quindi non sarebbe opportuno fornire troppi valori, poiché l'ordinamento richiede N log N tempo.

La mia esperienza ha dimostrato che sezionando l'insieme di valori in sottoinsiemi più piccoli e combinando i risultati di tutte le query nell'applicazione si ottengono le migliori prestazioni. Ammetto di aver raccolto esperienza su un database diverso (Pervasive), ma lo stesso può valere per tutti i motori. Il mio conteggio dei valori per set era 500-1000. Più o meno era significativamente più lento.