Normalmente los planificadores de consultas toman la decisión de eliminar los índices en la salida cuando el índice o la condición del JOIN no tiene la suficiente selectividad como para descartar un porcentaje importante de registros en el
matching. Es posible que esta sea la razón de por qué, en un conjunto mayor, donde se requiere leer una gran cantidad de bloques de datos, el porcentaje de registros a revisar termine siendo igual o mayor al 50% de lo leído, mientras que en el conjunto menor la cantidad de registros permite que sólo se use un bloque de lectura y por tanto el índice sea ventajoso.
Como regla general (que se enseña en las carreras de informática), si un conjunto dado de datos devueltos implica el 50% de la tabla, el tiempo de lectura termina siendo igual que leer toda la tabla (sólo le faltaría un salto más de lectura), por lo que el siguiente algoritmo a ejecutar sería el mismo que un
full scan. Entonces simplemente se decarta el ídice porque el overhead de leerlo se compensa con las lecturas que no se realizan en él. Directamente se pasa a la tabla.
Habría que analizar una a una las secciones de datos que se leen, para ver si afinando la lectura, puede reducirse el bloque a leer. Una idea sería transformar las tablas en tablas derivadas, y a su vez definirles indices en los campos que se requieren conocer (table2.prt__name Y table3.prt__name):
Código MySQL:
Ver original typex.*,
listM.prtc__col_name colM,
langs.prtc__col_name '__colName__',
langs.malg__code '__code__',
langs.`TEXT` '__text__'
table1 typex
(SELECT * FROM table2
WHERE prt__name
= 'gafas') langs
ON langs.prtx__ref
= typex.ref
(SELECT * FROM table3
WHERE prt__name
= 'gafas') listM
ON listM.prtx__ref
= typex.ref
typex.ref
IN ('0010021','0010022','0010023')