Cita:
Iniciado por Highlander 
EXPLAIN SELECT ID_CLIENTE, APE_CLIENTE_1, NOM_CLIENTE_1, DIR_CLIENTE, NAP, TELEFONO_CLIENTE, LOCALIDAD, NACIONALIDAD, VENDEDORA FROM cliente WHERE ESTADO_CLIENTE ='a' ORDER BY APE_CLIENTE_1, NOM_CLIENTE_1
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE cliente ref ESTADO_CLIENTE ESTADO_CLIENTE 5 const 1049 Using where; Using filesort
Segun lei si aparece filesort es harto negativo, estuve tratando de eliminarlo pero solo desaparece si elimino el ORDER BY.
Alguna idea, gracias.
El filesort no lo vas a poder eliminar sin eliminar el ORDER BY
porque precisamente lo que le estás diciendo es que lo ordene... Es obvio que aparecerá.
La aparición de un filesort no es
a priori algo negativo porque sí. Es negativo
según el contexto en que aparezca y la
cantidad de registros involucrados.
Si le indico a MySQL que me seleccione un X conjunto a través de un grupo de consultas anidadas, y a la selección final de 10 ó 100 registros le pido que los ordene, ¿qué importa? El tiempo de ordenamiento es casi inexistente en un conjunto tan pequeño.
Pero si la subconsulta de nivel 3 entre 8 niveles me está devolviendo
16.000.000 de registros tiene un ORDER BY, un filesort
es catastrófico por la cantidad de
tiempo de proceso involucrado.
Entonces: El problema que debes resolver no es que deje de existir el filesort en cuestión, sino que en el momento de invocarlo, el conjunto de datos seleccionado se haya reducido lo suficiente como para que el ORDER BY
no produzca una reducción de la performance de la consulta.
Por citar un ejemplo, una consulta que tengo definida para listar los conductores y vehículos que prestaron servicios (380 y 265 respectivamente), involucra el barrido de alrededor de 53.000.000 registros, de los que quedan aproximadamente medio millar y algo como resumen de servicios y sólo tiene un ORDER BY: al final. En ese contexto, la consulta tarda aproximadamente
48 segundos en realizarse, según hemos probado, incluyendo el almacenamiento de todos los registros. Si le quito el ORDER BY la consulta tarda aproximadamente
47 segundos... El problema, obviamente no está en el filesort, sino en la complejidad de la información leída.
¿Cómo pulimos esa consulta? Aprovechando que si la información está contenida en las claves de un índice, MySQL no lee la tabla, así que tres índices contienen en realidad el 70% de la información que se requiere, y con ello redujimos enormemente el problema.
