IN vs OR в предложении SQL WHERE

При работе с большими базами данных, которые работают лучше, INили ORв SQL- Whereпредложении?

Есть ли разница в том, как они выполняются?

Я предполагаю, что вы хотите знать разницу в производительности между следующими:

WHERE foo IN ('a', 'b', 'c')
WHERE foo = 'a' OR foo = 'b' OR foo = 'c'

Согласно руководству по MySQL, если значения постоянны, INсортирует список и затем использует двоичный поиск. Я полагаю, что ORоценивает их один за другим в произвольном порядке. Так INбыстрее в некоторых обстоятельствах.

Лучший способ узнать это - профилировать обе базы данных с вашими конкретными данными, чтобы увидеть, что быстрее.

Я пробовал оба на MySQL с 1000000 строк. Когда столбец индексируется, нет заметной разницы в производительности - оба практически мгновенные. Когда столбец не проиндексирован, я получил следующие результаты:

SELECT COUNT(*) FROM t_inner WHERE val IN (1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, 9000);
1 row fetched in 0.0032 (1.2679 seconds)

SELECT COUNT(*) FROM t_inner WHERE val = 1000 OR val = 2000 OR val = 3000 OR val = 4000 OR val = 5000 OR val = 6000 OR val = 7000 OR val = 8000 OR val = 9000;
1 row fetched in 0.0026 (1.7385 seconds)

Таким образом, в этом случае метод с использованием ИЛИ примерно на 30% медленнее. Добавление большего количества терминов увеличивает разницу. Результаты могут отличаться для других баз данных и других данных.

Лучший способ узнать это - посмотреть на План выполнения.

Я попробовал это с Oracle , и это было точно так же.

CREATE TABLE performance_test AS ( SELECT * FROM dba_objects );

SELECT * FROM performance_test
WHERE object_name IN ('DBMS_STANDARD', 'DBMS_REGISTRY', 'DBMS_LOB' );

Несмотря на то, что запрос использует IN, план выполнения говорит, что он использует OR:

--------------------------------------------------------------------------------------    
| Id  | Operation         | Name             | Rows  | Bytes | Cost (%CPU)| Time     |    
--------------------------------------------------------------------------------------    
|   0 | SELECT STATEMENT  |                  |     8 |  1416 |   163   (2)| 00:00:02 |    
|*  1 |  TABLE ACCESS FULL| PERFORMANCE_TEST |     8 |  1416 |   163   (2)| 00:00:02 |    
--------------------------------------------------------------------------------------    

Predicate Information (identified by operation id):                                       
---------------------------------------------------                                       

   1 - filter("OBJECT_NAME"='DBMS_LOB' OR "OBJECT_NAME"='DBMS_REGISTRY' OR                
              "OBJECT_NAME"='DBMS_STANDARD')                                              

Оператору OR требуется гораздо более сложный процесс оценки, чем конструкции IN, поскольку он допускает множество условий, не только равных, как IN.

Вот пример того, что вы можете использовать с ИЛИ, но которые не совместимы с IN: больше. больше или равно, меньше, меньше или равно, LIKE, а некоторые больше похожи на оракула REGEXP_LIKE. Кроме того, учтите, что условия не всегда могут сравнивать одно и то же значение.

Для оптимизатора запросов проще управлять оператором IN, потому что это только конструкция, которая определяет оператор OR для нескольких условий с оператором = для одного и того же значения. Если вы используете оператор ИЛИ, оптимизатор может не учитывать, что вы всегда используете оператор = для одного и того же значения, и, если он не выполняет более глубокую и гораздо более сложную разработку, он, вероятно, может исключить, что может быть только = операторы для одинаковых значений во всех задействованных условиях с последующим исключением оптимизированных методов поиска, таких как уже упомянутый двоичный поиск.

[EDIT] Вероятно, оптимизатор может не реализовать оптимизированный процесс оценки IN, но это не исключает, что это может произойти один раз (с обновлением версии базы данных). Так что если вы используете оператор ИЛИ, то оптимизированная разработка не будет использоваться в вашем случае.

Я думаю, что оракул достаточно умен, чтобы преобразовать менее эффективный (какой бы он ни был) в другой. Поэтому я думаю, что ответ должен скорее зависеть от читабельности каждого (где я думаю, что INявно выигрывает)

ORимеет смысл (с точки зрения читабельности), когда сравнивается меньше значений. INполезно особенно когда у вас есть динамический источник, с которым вы хотите сравнить значения.

Другая альтернатива - использовать JOINвременную таблицу.
Я не думаю, что производительность должна быть проблемой, если у вас есть необходимые индексы.

Я сделал запрос SQL в большом количестве ИЛИ (350). Postgres делает это 437.80мс .

Теперь используйте IN:

23.18ms