Leistung des MySQL-IN-Operators bei (großer?) Anzahl von Werten

Ich habe in letzter Zeit mit Redis und MongoDB experimentiert und es scheint, dass es häufig Fälle gibt, in denen Sie eine Reihe von IDs entweder in MongoDB oder in Redis speichern . Ich bleibe bei Redis für diese Frage, da ich nach dem MySQL IN- Operator frage .

Ich frage mich , wie performant ist es eine große Anzahl (300-3000) von zur Liste ids innerhalb des IN - Operator, die etwa wie folgt aussehen:

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

Stellen Sie sich etwas so Einfaches wie eine Produkt- und Kategorietabelle vor , die Sie normalerweise zusammenfügen, um die Produkte aus einer bestimmten Kategorie zu erhalten . Im obigen Beispiel können Sie sehen, dass category:4:product_idsich unter einer bestimmten Kategorie in Redis ( ) alle Produkt-IDs aus der Kategorie mit der ID 4 zurückgebe und sie in der obigen SELECTAbfrage innerhalb des INOperators platziere.

Wie performant ist das?

Ist das eine "es kommt darauf an" Situation? Oder gibt es ein konkretes "das ist (un) akzeptabel" oder "schnell" oder "langsam" oder sollte ich ein hinzufügen LIMIT 25, oder hilft das nicht?

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

Oder sollte ich das Array der von Redis zurückgegebenen Produkt-IDs kürzen, um es auf 25 zu beschränken, und nur 25 IDs zur Abfrage hinzufügen, anstatt 3000, und LIMITes innerhalb der Abfrage auf 25 hinzufügen ?

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

Anregungen / Feedback wird sehr geschätzt!

Wenn die INListe zu groß wird (für einen schlecht definierten Wert von "zu groß", der normalerweise im Bereich von 100 oder kleiner liegt), wird es im Allgemeinen effizienter, einen Join zu verwenden und bei Bedarf eine temporäre Tabelle zu erstellen die Zahlen zu halten.

Wenn die Zahlen eine dichte Menge sind (keine Lücken - was die Beispieldaten nahe legen), können Sie es noch besser machen WHERE id BETWEEN 300 AND 3000.

Vermutlich gibt es jedoch Lücken in der Menge. An diesem Punkt ist es möglicherweise besser, mit der Liste der gültigen Werte zu beginnen (es sei denn, die Anzahl der Lücken ist relativ gering. In diesem Fall könnten Sie Folgendes verwenden:

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

Oder was auch immer die Lücken sind.

Ich habe einige Tests durchgeführt, und wie David Fells in seiner Antwort sagt , ist es ziemlich gut optimiert. Als Referenz habe ich eine InnoDB-Tabelle mit 1.000.000 Registern erstellt und mit dem Operator "IN" mit 500.000 Zufallszahlen eine Auswahl getroffen. Auf meinem MAC dauert dies nur 2,5 Sekunden. Die Auswahl nur der geraden Register dauert 0,5 Sekunden.

Das einzige Problem, das ich hatte, war, dass ich den max_allowed_packetParameter aus der my.cnfDatei erhöhen musste . Wenn nicht, wird ein mysteriöser Fehler "MYSQL ist verschwunden" generiert.

Hier ist der PHP-Code, mit dem ich den Test mache:

$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>";

Und die Ergebnisse:

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

Sie können eine temporäre Tabelle erstellen, in die Sie eine beliebige Anzahl von IDs eingeben und eine verschachtelte Abfrage ausführen können. Beispiel:

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

und wählen Sie:

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

INist in Ordnung und gut optimiert. Stellen Sie sicher, dass Sie es in einem indizierten Feld verwenden und es Ihnen gut geht.

Es ist funktional äquivalent zu:

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

Was den DB-Motor betrifft.

Die Verwendung INmit einem großen Parametersatz für eine große Liste von Datensätzen ist in der Tat langsam.

In dem Fall, den ich kürzlich gelöst habe, hatte ich zwei where-Klauseln, eine mit 2,50 Parametern und die andere mit 3.500 Parametern, die eine Tabelle mit 40 Millionen Datensätzen abfragten.

Meine Anfrage dauerte 5 Minuten mit dem Standard WHERE IN. Indem ich stattdessen eine Unterabfrage für die IN- Anweisung verwendete (die Parameter in eine eigene indizierte Tabelle einfügte ), wurde die Abfrage auf ZWEI Sekunden reduziert.

Arbeitete meiner Erfahrung nach sowohl für MySQL als auch für Oracle.

Wenn Sie viele Werte für den INOperator angeben, muss dieser zuerst sortiert werden, um Duplikate zu entfernen. Zumindest vermute ich das. Es wäre also nicht gut, zu viele Werte anzugeben, da das Sortieren N log N Zeit benötigt.

Meine Erfahrung hat gezeigt, dass das Aufteilen der Wertemenge in kleinere Teilmengen und das Kombinieren der Ergebnisse aller Abfragen in der Anwendung die beste Leistung ergibt. Ich gebe zu, dass ich Erfahrungen in einer anderen Datenbank (Pervasive) gesammelt habe, aber das Gleiche gilt möglicherweise für alle Engines. Meine Anzahl von Werten pro Satz war 500-1000. Mehr oder weniger war deutlich langsamer.