Problemas con LOW QUERY Mysql

[syntex]

Hola buenas,

Estoy visualizando las Low Query y tengo una consulta de tipo:

Código MySQL:

SELECT
            id,texto_1,foto,ocultar_reg_gratis
        FROM
            servicios_cat as a
        WHERE
        (
            fecha != ''
        )
        ORDER BY 
            ordenado ASC;
 

Donde poner el indice?

Actualmente tengo:

Código SQL:

ALTER TABLE  `servicios_cat` ADD INDEX  `servicios_cat3` (  `fecha` );
 

Pero me dice:

Código MySQL:

# Time: 130311  7:08:01
# User@Host: xxxx[xxxxx] @ localhost [127.0.0.1]
# Query_time: 0.000000  Lock_time: 0.000000 Rows_sent: 6  Rows_examined: 12
SET timestamp=1362982081;
SELECT
            id,texto_1,foto,ocultar_reg_gratis
        FROM
            servicios_cat as a
        WHERE
        (
            fecha != ''
        )
        ORDER BY 
            ordenado ASC;
 

Muchas gracias

[gnzsoloyo]

Ajá... Y lo que quieres saber sería...



¿Qué?

Recordemos que una "low query" es una consulta que lleva más tiempo que el definido en un parámetro configurable de MySQL, y se suele utilizar para saber qué consultás podrían ser optimizadas.

Lo que sí creo que no tienes claro es que un campo de fecha no puede contener un espacio vacío. O es NULL, o bien contiene una fecha en cero, pero no es un espacio vacío porque un campo de fecha no es un VARCHAR... a menos que hayas cometido el enorme error de poner la fecha en un VARCHAR... Lo que podría explicar el problema de performance.

[syntex]

Me gustaría saber que indice tendría que crear sobre esta consulta para que no tenga en el log LOW QUERY

[gnzsoloyo]

Puede no ser necesariamente un índice, sino los datos o los parámetros de búsqueda.
Por lo pronto, cuando buscas fechas, si no buscas un rango o una fecha, es mejor qu eel campo a buscar esté en '000000-00-00', o bien sea nulable, porque eso sí impactaría en el uso del índice.
Pero cuando buscas algo que sea "distinto de", el parser no puede, desde el principio, establecer cuál de los valores del índice es diferente, por lo que descarta el uso del mencionado índice y pasa a realizar un tablescan, lo que es el peor escenario posible en cualquier DBMS.
¿Se entiende?
Además de eso, es conveniente no abusar de los paréntesis, y usarlos sí y sólo si es necesario, que no es tu caso, porque pueden tener un mal impacto en el plan de la consulta.

Por otro lado, no me has respondido: ¿Cómo tienes configurado el campo de la fecha?

[syntex]

Y si eliminó el where no pondría indices por Que la consulta mostrada arriba es lo mismo Que sin el where por Que todos los registros fecha están Como 2013-04-01 Como ejemplo.
Eliminare todos los paréntesis del where si no son necesarios.

Entonces en el Log Query siempre me lo mostrará?

Aré indices a buscar en el where y no Como IS NOT

[gnzsoloyo]

Tengo la impresión de que sigues sin entenderme bien.
1) ¿Qué tipo de dato usa la columna "fecha"?
2) Te conviene que sea nulable.
3) En las fechas, es preferible hacer búsquedas por rango, y no por diferente a.
4) Las búsquedas por "diferente de" son siempre ineficientes. Generan table scan.
5) El WHERE no es optimizable, pero puede determinar si aprovechará os índices.
6) No se puede determinar a priori que una consulta el el LOW QUERY implique ineficiencia de consulta, porque eso dependerá de varios factores. Que aparezca o no, lo determina el tiempo definido en su variable de sistema. Pero si esa variable estuviese puesta en 20 segundos, por ejemplo, y la consulta dura 21 segundos, tu supones que es lenta, y eso puede no ser necesariamente cierto.
Una consulta puede ser rápida con 230 segundos de duración, si procesase, por ejemplo, 2.000.000.000 de registros, realizando JOINS con otras tablas con 10.000.000 registros para obtener algunos miles de registros resultantes. Y en ese contexto, no creo que podamos hablar de una consulta "lenta"... ¿No te parece?
En tu caso, podemos decir, sin siquiera mirar el log de low query, que tu consulta es ineficiente incluso aunque la tabla tuviese 10 registros. Y se puede decir eso porque el "fecha != ''" es de entrada una condición absolutamente ineficiente. Ni siquiera tengo que ejecutarla para saber que es mala.
¿Se va entendiendo?
No es sólo la estritura, ni los indices. Es el contexto lo que define si es o no optimizable.
El LOW QUERY es una guía, no una definición absoluta.