equal - mysql operators

Diferencias de rendimiento entre igual(=) e IN con un valor

Question

¿Cómo difieren los motores SQL cuando usamos signo igual y el operador IN tiene el mismo valor? ¿Cambia el tiempo de ejecución?

1er usando operador de verificación de igualdad

WHERE column_value = ''All''

2do usando operador OR y valor único

WHERE column_value IN (''All'')

¿El motor SQL cambia IN a = si solo hay un valor?

¿Hay alguna diferencia para lo mismo en MySQL y PostgreSQL?

Answer 1

Deberá ejecutar un plan de ejecución en ambos y ver los resultados.

Creo que tendrán el mismo plan de ejecución, ya que se realizará igual que un signo normal = cuando solo se coloca un valor dentro de la instrucción IN() .

No hay ninguna razón para que el optimizador se comporte de manera diferente en una consulta como esta.

Answer 2

Enseñe a un hombre a pescar, etc. A continuación, le mostramos cómo ver por sí mismo qué variaciones harán en sus consultas:

mysql> EXPLAIN SELECT * FROM sentence WHERE sentence_lang_id = "AMH"/G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: sentence
         type: ref
possible_keys: sentence_lang_id
          key: sentence_lang_id
      key_len: 153
          ref: const
         rows: 442
        Extra: Using where

Y probémoslo de la otra manera:

mysql> EXPLAIN SELECT * FROM sentence WHERE sentence_lang_id in ("AMH")/G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: sentence
         type: ref
possible_keys: sentence_lang_id
          key: sentence_lang_id
      key_len: 153
          ref: const
         rows: 442
        Extra: Using where

Puede leer here sobre cómo interpretar los resultados de una solicitud EXPLAIN mysql. Por ahora, tenga en cuenta que obtuvimos resultados idénticos para ambas consultas: se genera exactamente el mismo "plan de ejecución". La fila de type nos dice que la consulta usa un índice no único (una clave foránea, en este caso), y la fila de ref nos dice que la consulta se ejecuta comparando un valor constante con este índice.

Answer 3

No hay diferencia cuando lo está utilizando con un solo valor. Si verifica el escaneo de la tabla, el escaneo de índice o la búsqueda de índice para las dos consultas anteriores, encontrará que no hay diferencia entre las dos consultas.

¿Hay alguna diferencia para lo mismo en Mysql y PostgresSQL?

No, no tendría ninguna diferencia en los dos motores (de hecho, sería lo mismo para la mayoría de las bases de datos, incluidos SQL Server, Oracle, etc. ). Ambos motores convertirán IN a =

Answer 4

No hay diferencia entre esas dos declaraciones, y el optimizador transformará el IN a = cuando IN solo tiene un elemento en él.

Aunque cuando tenga una pregunta como esta, simplemente ejecute ambas declaraciones, ejecute su plan de ejecución y vea las diferencias. Aquí, no encontrarás ninguno.

Después de una gran búsqueda en línea, encontré un documento en SQL para respaldar esto (supongo que se aplica a todos los DBMS):

Si solo hay un valor dentro del paréntesis, esta recomendación es equivalente a

WHERE "column_name" = ''value1

Aquí está el enlace al documento .

Aquí está el plan de ejecución de ambas consultas en Oracle (la mayoría de DBMS procesará esto de la misma manera):

EXPLAIN PLAN FOR
select * from dim_employees t
where t.identity_number = ''123456789''

Plan hash value: 2312174735
-----------------------------------------------------
| Id  | Operation                   | Name          |
-----------------------------------------------------
|   0 | SELECT STATEMENT            |               |
|   1 |  TABLE ACCESS BY INDEX ROWID| DIM_EMPLOYEES |
|   2 |   INDEX UNIQUE SCAN         | SYS_C0029838  |
-----------------------------------------------------

Y para IN() :

EXPLAIN PLAN FOR
select * from dim_employees t
where t.identity_number in(''123456789'');

Plan hash value: 2312174735
-----------------------------------------------------
| Id  | Operation                   | Name          |
-----------------------------------------------------
|   0 | SELECT STATEMENT            |               |
|   1 |  TABLE ACCESS BY INDEX ROWID| DIM_EMPLOYEES |
|   2 |   INDEX UNIQUE SCAN         | SYS_C0029838  |
-----------------------------------------------------

Como puede ver, ambos son idénticos. Esto está en una columna indexada. Lo mismo ocurre con una columna no indexada (solo exploración de tabla completa).

Answer 5

Para una sola cláusula IN, no hay diferencia ... a continuación se muestra una demostración usando una tabla EMPS que tengo ...

select * from emps where empid in (1)
select * from emps where empid=1

Predicado para la primera consulta en el plan de ejecución:

[PerformanceV3].[dbo].[Emps].[empID]=CONVERT_IMPLICIT(int,[@1],0)

Predicar para la segunda consulta en el plan de ejecución:

[PerformanceV3].[dbo].[Emps].[empID]=CONVERT_IMPLICIT(int,[@1],0)

Si tiene varios valores en la cláusula IN, es mejor convertirlos en uniones

Answer 6

Realmente no hay grandes diferencias, pero si su valor de columna está indexado, el operador IN puede no leerlo como un índice.

Encontré este problema una vez, así que tenga cuidado.

Answer 7

Solo para agregar una perspectiva diferente, uno de los puntos principales de los sistemas rdbms es que reescribirán su consulta por usted y elegirán el mejor plan de ejecución para esa consulta y todos los equivalentes. Esto significa que siempre y cuando dos consultas sean lógicamente idénticas, siempre deberían generar el mismo plan de ejecución en un rdbms dado.

Dicho esto, muchas consultas son equivalentes (el mismo conjunto de resultados) pero solo debido a las restricciones de las que la base de datos no es consciente, así que tenga cuidado con esos casos (por ejemplo, para un campo de marca con números 1-6, el db no sabe <3 es lo mismo que in (1,2) ). Pero al final del día, si solo está pensando en la legibilidad de las declaraciones y / or no, no habrá una diferencia en el rendimiento en la forma en que las escriba.