Desgasta + SELECT WHERE user = 'string de 1000' ó SELECT WHERE user = 'string de 10'?

[Anarko]

Hola.

Tóma + tiempo para MySQL hacer un

SELECT * WHERE campo = 'abcdefghijklmnopqrstunwxyz'

ó

SELECT * WHERE campo = 'abc'

????

El string es notoriamente + extenso, pero se está utilizando

[WHERE campo "SÉA IGUAL"]

Así que se desgasta + el servidor buscando un STRING largo que uno CORTO ?

El campo es un VARCHAR de 256.


Gracias!

[Libras]

Si tienes el campo indexado el "desgaste" seria minimo ya que mysql tendria la base para buscar los campos tomando en cuenta el valor a buscar, en cuanto a la longitud de la cadena el desgaste seria el mismo....

[Anarko]

Iniciado por Libras

...en cuanto a la longitud de la cadena el desgaste seria el mismo...

ése precisamente es "mi interrogante"...

Será que string LARGO = servidor + desgastado????...

[Libras]

Depende la longitud de la cadena, digamos si metes una cadena de 8000 caracteres, y sobre esa haces tus busquedas sin indices, si seria mas "desgastante" para tu server, pero OJO tambien habria que revisar realmente cual es el impacto de este desgaste, podria ser algo minimo

[Anarko]

Iniciado por Libras

Depende la longitud de la cadena, digamos si metes una cadena de 8000 caracteres, y sobre esa haces tus busquedas sin indices, si seria mas "desgastante" para tu server, pero OJO tambien habria que revisar realmente cual es el impacto de este desgaste, podria ser algo minimo

Gracias.

Se trata de utilizar where campo = 'abc' y no de utilizar LIKE %abc%.

Es por ello que aunque "puede" presuponerse que encontrar STRING_de_1000 es + complejo que encontrar STRING_de_10, hago la pregunta.

[gnzsoloyo]

Iniciado por Anarko

Gracias.

Se trata de utilizar where campo = 'abc' y no de utilizar LIKE %abc%.

Es por ello que aunque "puede" presuponerse que encontrar STRING_de_1000 es + complejo que encontrar STRING_de_10, hago la pregunta.

No son casos iguales, ni siquiera semejantes.

Un "=" implica igualdad, estrictamente, y para las igualdades el plan de consultas cumple ciertas codiciones de larga enumeración.
En esencia, como ya te dijeron, el hecho de que el campo esté indexado permite al DBMS elegir entre algoritmos optimizados para ese caso, cual sería la mejor estrategia. Uno de los valores iniciales es verificar si alguna de las claves del indice tiene la misma longitud como cadena, por ejemplo, ya que de ser asì el DBMS solo recuperará los valores que cumplan la condición y descartará el resto.
Esto es solo a modo de ejemplo de la lógica de un plan de consulta.
Por lo básico, si una comparacion puede ser cumplida por la mitad o menos de los registros en el indice, el indice se utiliza para acelerar las consultas y es muy efectivo.

Pero no es el caso de usar "%", en especial en ambos lados de la cadena.
Eso se usa con LIKE, es búsqueda por PATRONES. Esto implica que no busca cosas que sean "iguales a", sino "parecidas a", lo que marca una ENORME diferencia lógica. Los algoritmos son completamente diferentes.
Para decirlo en pocas palabras: Poner los comodines a ambos lados obliga a el DBMS a comparar absolutamente TODOS los registros del indice, dado que la cantidad de caracteres a derecha o izquierda son INDETERMINADOS, por lo que tendrá que mirar uno a uno todos los registros.
En tal situación usualmente el índice simplemente es descartado, y el DBMS sencillamente barre la tabla completa, en el peor tipo de consulta posible: FULL TABLE SCAN, la asesina de performance.

¿Se entiende?