（大きい？）数の値に対するMySQLの「IN」演算子のパフォーマンス

Question 1

私は最近RedisとMongoDBを試していますが、MongoDBまたはRedisのいずれかにIDの配列を格納する場合が多いようです。MySQL IN演算子について質問しているので、この質問についてはRedisを使用します。

IN演算子内に多数（300〜3000）のIDをリストすることは、どれほどパフォーマンスが高いのか疑問に思いました。これは次のようになります。

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

通常は一緒に結合して特定のカテゴリから製品を取得する、製品とカテゴリのテーブルのような単純なものを想像してみてください。上記の例では、Redis（）の特定のカテゴリの下で、ID 4のカテゴリからすべての製品IDを返し、演算子内の上記のクエリに配置していることがわかります。category:4:product_idsSELECTIN

これはどのくらいのパフォーマンスですか？

これは「状況によって異なります」ですか？または、具体的な「これは（受け入れられない）」または「速い」または「遅い」LIMIT 25がありますか、それとも追加する必要がありますか、それとも役に立ちませんか？

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

または、Redisによって返される製品IDの配列をトリミングして25に制限し、クエリLIMIT内から3000ではなく25 IDのみをクエリに追加して25に追加する必要がありますか？

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

任意の提案/フィードバックは大歓迎です！

Question 2

一般的に、INリストが大きくなりすぎると（通常、100以下の領域にある「大きすぎる」という不明確な値の場合）、結合を使用する方が効率的になり、必要に応じて一時テーブルを作成します。数字を保持します。

数値が密な集合である場合（ギャップがない-サンプルデータが示唆している）、を使用するとさらにうまくいくことができますWHERE id BETWEEN 300 AND 3000。

ただし、おそらくセットにギャップがあるため、結局のところ、有効な値のリストを使用する方がよい場合があります（ギャップの数が比較的少ない場合を除き、次のように使用できます。

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

またはギャップが何であれ。

Question 3

私はいくつかのテストを行ってきましたが、David Fellsが彼の回答で述べているように、それは非常によく最適化されています。参考までに、1,000,000個のレジスターを含むInnoDBテーブルを作成し、500,000個の乱数を使用して「IN」演算子を使用して選択を実行しました。MACではわずか2.5秒しかかかりません。偶数レジスタのみを選択するのに0.5秒かかります。

私が抱えていた唯一の問題はmax_allowed_packet、my.cnfファイルからパラメータを増やす必要があることです。そうでない場合は、不思議な「MYSQLがなくなりました」というエラーが生成されます。

テストを行うために使用するPHPコードは次のとおりです。

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

そして結果：

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

Question 4

任意の数のIDを配置し、ネストされたクエリを実行できる一時テーブルを作成できます。例：

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

選択します：

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

Question 5

INレコードの大きなリストで大きなパラメータセットを使用すると、実際には時間がかかります。

最近解決した場合、2つのwhere句がありました。1つは2,50のパラメーターを持ち、もう1つは3,500のパラメーターを持ち、4,000万レコードのテーブルをクエリします。

私のクエリは、標準を使用して5分かかりましたWHERE IN。代わりに、INステートメントのサブクエリを使用する（パラメーターを独自のインデックス付きテーブルに配置する）ことで、クエリを2秒に短縮しました。

私の経験では、MySQLとOracleの両方で働いていました。

Question 6

INうまく、よく最適化されています。インデックス付きフィールドで使用することを確認してください。問題はありません。

機能的には次のものと同等です。

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

DBエンジンに関する限り。

Question 7

IN演算子に多くの値を指定する場合、最初に演算子を並べ替えて重複を削除する必要があります。少なくとも私はそれを疑う。したがって、ソートにはN log N時間がかかるため、あまり多くの値を指定するのは適切ではありません。

私の経験では、値のセットを小さなサブセットにスライスし、アプリケーション内のすべてのクエリの結果を組み合わせると、最高のパフォーマンスが得られることが証明されました。別のデータベース（Pervasive）で経験を収集したことは認めますが、同じことがすべてのエンジンに当てはまる可能性があります。セットあたりの値の数は500〜1000でした。多かれ少なかれかなり遅かった。