resueltos - sql server query to html table

¿Algún impacto en el rendimiento de Oracle al usar LIKE ''cadena'' vs=''cadena''?

Question

Esta

SELECT * FROM SOME_TABLE WHERE SOME_FIELD LIKE ''%some_value%'';

es más lento que esto

SELECT * FROM SOME_TABLE WHERE SOME_FIELD = ''some_value'';

pero ¿qué hay de esto?

SELECT * FROM SOME_TABLE WHERE SOME_FIELD LIKE ''some_value'';

Mi prueba indica que el segundo y el tercer ejemplo son exactamente lo mismo. Si eso es cierto, mi pregunta es, ¿por qué usar "="?

Answer 1

Si eso es cierto, mi pregunta es, ¿por qué usar "="?

Una pregunta mejor: si eso es cierto, ¿por qué usar "ME GUSTA" para probar la igualdad? Puedes guardar presionando la tecla Mayús y todos los que leen el guión se confunden.

Answer 2

¿Lo has probado? Las pruebas son la única forma segura de saberlo.

Como comentario aparte, ninguna de estas afirmaciones devolverá las mismas filas. Probar:

insert into some_table (some_field) values (''some_value'');
insert into some_table (some_fieled) values (''1some_value2'');
insert into some_table (some_field) values (''some1value'');

SELECT * FROM SOME_TABLE WHERE SOME_FIELD LIKE ''%some_value%'';

SELECT * FROM SOME_TABLE WHERE SOME_FIELD = ''some_value'';

SELECT * FROM SOME_TABLE WHERE SOME_FIELD LIKE ''some_value'';

En términos de claridad y para evitar errores sutiles, lo mejor es nunca utilizar LIKE a menos que lo necesite es la funcionalidad comodín. (Obviamente, cuando se realizan consultas ad-hoc, es probable que esté bien).

Answer 3

Consulte el PLAN EXPLICACIÓN para ambos. Generan el mismo plan de ejecución, por lo que para la base de datos, son lo mismo.

Usaría = para probar la igualdad, no la similitud. Si también está controlando el valor de comparación, entonces no hace mucha diferencia. Si un usuario lo envía, entonces ''apple'' y ''apple%'' le darán resultados muy diferentes.

Answer 4

LIKE ''% WHATEVER%'' tendrá que hacer un escaneo de índice completo.

Si no hay un porcentaje, entonces actúa como un igual.

Si el% está en un extremo, entonces el índice puede ser un escaneo de rango.

No estoy seguro de cómo el optimizador maneja los campos enlazados.

Answer 5

Existe una clara diferencia cuando utiliza variables de vinculación, que debería utilizar en Oracle para cualquier otra cosa que no sea el almacenamiento de datos u otras operaciones de datos masivos.

Toma el caso de:

SELECT * FROM SOME_TABLE WHERE SOME_FIELD LIKE :b1

Oracle no puede saber que el valor de: b1 es ''% some_value%'', o ''some_value'' etc. hasta el momento de la ejecución, por lo que hará una estimación de la cardinalidad del resultado en función de la heurística y elaborará un plan apropiado que puede o no ser adecuado para varios valores de: b, como ''% A'', ''%'', ''A'', etc.

Se pueden aplicar problemas similares con un predicado de igualdad, pero el rango de cardinalidades que podría resultar se puede estimar mucho más fácilmente basándose en estadísticas de columna o la presencia de una restricción única, por ejemplo.

Entonces, personalmente, no comenzaría a utilizar LIKE como reemplazo de =. El optimizador es bastante fácil de engañar a veces.

Answer 6

like que formalmente es lo mismo si no tiene caracteres como $% etc. por lo que no es una gran sorpresa encontrar que tiene el mismo costo.

Encuentro interesante la respuesta de David Aldridge, ya que su aplicación debería usar variables de vinculación. Con un like ''%foobar'' no puede hacer uso de ordenar en el índice. Si la consulta está precompilada, dará lugar a más Escaneos completos de índice o tabla.

Además, me parece peligroso ya que puede provocar inyecciones de SQL y errores extraños (por ejemplo, si hay un usuario llamado John, un hacker puede crear un usuario llamado ''joh$'' e intentar iniciar sesión)

¿por qué tomar el riesgo? ''='' es más claro y no tiene ninguno de esos problemas.