equal - mysql operators
Diferencias de rendimiento entre igual(=) e IN con un valor (7)
¿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?
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.
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.
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
=
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).
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
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.
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.