Cita:
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?