Сообщение от moka
Скорость работы IN, в зависимости от запроса может умножать сложность запроса кратной элементов в IN.
Так что если делаешь запрос на IN 10 ID например, то это скорее всего приведет к 10 кратному усложнению запроса, следственно в 10 дольше будет генерировать ответ. И это в хорошем случае когда индексы используются.
|
SELECT * FROM some_table
будет в 10 раз быстрее чем
SELECT * FROM some_table WHERE id IN [1, 5, 7]
??
херню понаписал как всегда.
Без индексов все может быть похуже, если первым используется другое поле, и затем из профильтрованных значений нужно делать проверку. То либо будет создаваться мелкий временный индекс по меньшему списку проверямых данных, и еще одна итерация по полям для сравнения, либо вообще O(a*b), что я надеюсь в дб движке избежали используя временный индекс.
Если используется временный индекс, то это использует RAM, индексы обычно легкие.
|
Во-первых, вот это -
либо вообще O(a*b) объясни своими словами,
Во-вторых, какие еще временные индексы ? По твоему мнению по каким данным база должна построить "временный индекс" ?? Приведи пример запроса (с IN, разумеется) в котором использование этого самого "временного индекса" даст преимущество.
Не смотря на все это, использование IN с очень большими списками не рекомендуется.
Порой можно избежать подобного и структурировать данные более удобно для таких целей.
|
IN на 1000 или на 2000 вообще не проблема.