Ver Mensaje Individual
  #6 (permalink)  
Antiguo 28/10/2008, 18:22
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años, 3 meses
Puntos: 2658
Respuesta: Optimizar Consulta (eliminar Filesort)

Cita:
Iniciado por Highlander Ver Mensaje
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.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)