Problemas de ejecución con un SELECT

[xinxan22]

Buenos días,

estoy haciendo un select como el siguiente:




SELECT campo1
FROM informes_tabla
WHERE (fecha_on>='2012-03-09 00:00:00' AND fecha_off<='2012-03-09 23:59:59') AND id='1'
GROUP BY fecha_1
ORDER BY fecha_1 ASC;



y me tarda más de 40 segundos,

luego hago el siguiente select:


SELECT campo1
FROM informes_tabla
WHERE (fecha_on>='2012-03-09 00:00:00' AND fecha_off<='2012-03-09 23:59:59') AND id='23'
GROUP BY fecha_1
ORDER BY fecha_1 ASC;



y me tarda 1 segundo




El mismo SELECT con un id diferente me tarda de 1 segundo a 40 segundos.

Cual podría ser el problema?


- El campo "id" lo tengo indexado y es una clave forana de otra tabla


- Lo he ejecutado varias veces y el tiempo varía:

de 40 a 50 segundos

el otro de 1 a 1.5 segundos


- El resultado del SELECT es 1 solo registro para ámbos ids.

[quimfv]

La explicacion debe estar en la relacion que hay entre fecha_1 y el id.... si id=1 tiene muchos registros con la misma fecha_1 .... y id=23 solo uno....

Si id es un INTEGER te sobran los delimitadores id=1 no id='1'

Si de id=X hay un solo registro no se explica pero luego no tendria sentido hacer group by...

Pregunta: Que sentido tiene hacer un group by si no usas ninguna función de agregado...ni muestras el campo por el que agregas...?

[xinxan22]

Hola,

el Group by lo estoy utilizando porque se están insertando registros en esta tabla repetidos (misma fecha, id, etc...) de momento lo estoy haciendo así hsata que no tenga controlado la duplicación de inserts....


Por otro lado, id es VARCHAR (14), estoy optimizando para cambiarlo a BIGINT ya que un INTEGER me quedaría corto


En esta tabla pueden haber varios registros con fecha de ayer o de hoy o de la semana pasada con el mismo id=1 o con el mismo id=23.


Si quito el group by (lo cual para el id=1 y el id=23 no hay duplicados) el tiempo del SELECT es exactamente igual.


El resultado del SELECT para el id=1 --> es 1 registro
El resultado del SELECT para el id=23 --> es 1 registro



Haciendo un

SELECT count(*) FROM tabla WHERE id=1 ---> 10396 registros
SELECT count(*) FROM tabla WHERE id=23 ---> 59 registros


Puede ser eso? que en uno tiene que tener en cuenta esa cantidad de registros mientras que en la otra son menos?

[quimfv]

Pues a ti que te parece...

Si es un problema de eliminar duplicados, que deberías solucionar por otro lado, porque no haces esto

Código MySQL:

SELECT campo1
FROM informes_tabla
WHERE (fecha_on>='2012-03-09 00:00:00' AND fecha_off<='2012-03-09 23:59:59') AND id='1' 
LIMIT 1;
 

Un indice sobre las fechas_on y off tambien podria ayudar....

[xinxan22]

He terminado reiniciando el servidor y ahora está funcionando perfectamente... tarda 1 segundo o menos ahora en hacer las consultas

[xinxan22]

Nada, pensé que el reinicio del servidor funcinoaba pero ha vuelto a ir lento (seguramente leía de caché).

Con ese select LIMIT 1 solo me devolverá un registro y necesito todos los de hoy o e una fecha en concretro.


El id es una clave forana a otra tabla, podría ser la causa de la lentitud?

[calakra]

Hola.

No entiendo bien es que lo que quieres trae, deberias poner un ejemplo para darnos una idea de que es lo que quieres.

Por otro lado he de decir que soy nuevo en MySQL pero te comentaré lo que me paso una vez con Postgresql y no se si exista su equivalente en este gestor.

Teniamos un query que se ejecutaba en las noches, pero aveces llegaba a tardar mas de 8 horas y cuadno regresabamos aun no terminaba el proceso, asi que nos pusimos a investigar y se descubrio que a la base de datos se le daba su mantenimiento, en postgres usabamos el comando vacuum y reindex y despues de ejecutar esas instrucciones la base iva super rapido, hay que tener claro que pra darle su mantenimiento llevaba tiempo asi que no si si se le pueda dar una manita de gato a la base de datos.

Saludos y espero que resuelbas tu problema para que nos digas como lo hiciste. saludos!!!

[calakra]

Mira buscando algo me encontre con esto http://dev.mysql.com/doc/refman/5.0/...istration.html

Vete a sentencias de mantenimiento y ahi me dices que paso.

Saludos

[xinxan22]

Iniciado por calakra

Hola.

No entiendo bien es que lo que quieres trae, deberias poner un ejemplo para darnos una idea de que es lo que quieres.

Por otro lado he de decir que soy nuevo en MySQL pero te comentaré lo que me paso una vez con Postgresql y no se si exista su equivalente en este gestor.

Teniamos un query que se ejecutaba en las noches, pero aveces llegaba a tardar mas de 8 horas y cuadno regresabamos aun no terminaba el proceso, asi que nos pusimos a investigar y se descubrio que a la base de datos se le daba su mantenimiento, en postgres usabamos el comando vacuum y reindex y despues de ejecutar esas instrucciones la base iva super rapido, hay que tener claro que pra darle su mantenimiento llevaba tiempo asi que no si si se le pueda dar una manita de gato a la base de datos.

Saludos y espero que resuelbas tu problema para que nos digas como lo hiciste. saludos!!!

El problema es que estoy intentando hacer un SELECT y tarda unos 40 segundos o más en ejecutarse.
Hago ese mismo select pero con otro id y me tarda 1 segundo.

(mirar mi primer mensaje en este post)

He hecho un check table, repair table, optimize table, he reiniciado la base de datos....

La pregunta es si esa lentitud puede ser por la foreing key que tiene el id a otra tabla..

[xinxan22]

Buenos días,
he modificado el "table engine" a MyIsam y ahora va perfectamente rapidísimo.
Antes tenía inoodb.

Pero ahora no puedo utilizar foreing keys!!!

[gnzsoloyo]

Porque en las MyISAM no existen las FK.
Cambiar el motor es una pésima idea, para una base en producción. Debería haber tratado de solucionar el problema y no hacer "parches".

[xinxan22]

Ya lo se pero entonces el problema de lentitud es por ser innodb ?

[gnzsoloyo]

No necesariamente. InnoDB hace un poco más lentos los INSERT, UPDATE y DELETE, pero los SELECT no varían demasiado entre MyISAM e InnoDB, al menos para tu caso.
Lo grave es que tengas duplicaciones de una ID (¿puedes explicarme cómo es que se puede duplicar? ¿Cuál es la PK de esa tabla?), y que debas recurrir a GROUP BY para eliminarlas.
Bueno, uno de los problemas es que en esa consuta invocas a las dos cláusulas menos performánticas que existen: ORDER BY y GROUP BY. Si quieres tener problemas con la velocidad, es el mejor modo.
Pero algo de eso ya te lo habían dicho.
Otro de los defectos es que ciertas validaciones las estás haciendo muy grandes innecesariamente.
Esto es poco eficiente:

Código MySQL:

(fecha_on>='2012-03-09 00:00:00' AND fecha_off<='2012-03-09 23:59:59')
 

Esto es más siple, porque requiere casi la mitad de memoria:

Código MySQL:

DATE(fecha_on)>='2012-03-09' AND DATE(fecha_off) <='2012-03-09'
 

También debe considerarse que si bien puedes hacer indices de tipo INDEX sobre el "ID", sería mejor crear un índice entre el "campo1" y la fecha_on, por ejemplo. Eso podría mejorar la cosa teniendo e cuenta que cuando un índice usado contiene los datos que se mostrarán, normalmente MySQL no lee la tabla de datos, sino que saca todo del índice.
Una posibilidad a probar sería, por ejemplo, crear una tabla TEMPORARY con un índice UNIQUE definido sobre los cuatro campos en cuestión y lueg consultarla... Podría andar.

[xinxan22]

pues ... la tabla tiene un id_tabla autonumérico...

El id que consulto es el id_tabla2

tabla1: id_tabla, fecha_on, fecha_off, id_tabla2(FK .. indexado)

tabla2: id_tabla2, campos...


en la tabla 1 tengo N registros, de un día por ejemplo tengo 20 registros y de otor día 10 registros.

Uso GROUP BY porque el aplicativo que hace INSERTS en esa tabla repite registros con lo cual tengo algunos registros con fecha_hora iguales.

Uso el ORDER BY para que apareza del primer registro del día al último registro del día.

Uso el WHERE con la fecha y hora ya que el usuario tiene un formulario como el siguiente:

FECHA ON: 01/01/2012 00:00:00
FECHA OFF: 12/03/2012 13:00:00

Nota: Sin el group by el select me tarda lo mismo en ejecutarse


El problema inicial de todo esto es que haciendo el mismo select con un id_Tabla2 diferente (misma fecha_hora de on y de off) el tiempo pasaba de 1 segundo a 40 segundos.

Lo he estado probando todo y cuando he modificado el motor de innobd a MyIsam es cuando he conseguido que los dos selects no pasen de 1 segundo (0,0...s)


No entiendo porque pasaba esto antes y ahora he perdido la integridad referencial de las FK.

[gnzsoloyo]

Uso GROUP BY porque el aplicativo que hace INSERTS en esa tabla repite registros con lo cual tengo algunos registros con fecha_hora iguales.

Uso el ORDER BY para que apareza del primer registro del día al último registro del día.

Eso ya te lo había entendido. Mi intención es que comprendas que uno de tus problemas es que estés necesitando usar esas cláusulas, porque son esas cláusulas las que ayudan a que sea lento.
Lo mejor sería no tener que usarlas, y para ello hay algunas alternativas, como la que te menciono al final de mi post.

Uso el WHERE con la fecha y hora ya que el usuario tiene un formulario como el siguiente:

FECHA ON: 01/01/2012 00:00:00
FECHA OFF: 12/03/2012 13:00:00

Lo que el usuario vea en su formulario en este caso es irrelevante. Lo que importa es el rango de datos que estás buscando en la consulta:

Código MySQL:

SELECT campo1
FROM informes_tabla
WHERE (fecha_on>='2012-03-09 00:00:00' AND fecha_off<='2012-03-09 23:59:59') AND id='1'
GROUP BY fecha_1
ORDER BY fecha_1 ASC;
 

Lo que traducido a una frase sería: "Todo lo igual o posterior al primer segundo del 09/02/2012, y anterior o igual al último segundo del día 09/02/2012".
Y eso es lo mismo que poner:

Código MySQL:

SELECT campo1
FROM informes_tabla
WHERE 
    DATE(fecha_on)>='2012-03-09' AND DATE(fecha_off)<='2012-03-09') 
     AND id=1
GROUP BY fecha_1
ORDER BY fecha_1 ASC;
 

Con la diferencia que la primera necesita 8 Bytes por dato y la otra 3. Lo que a nivel de procesamiento hace una buena diferencia.

Por otro lado, respecto a que dos ejecuciones tarden diferente, aún con los mismos datos, no es extraño, porque la resolución de los planes de consulta por el parser puede variar de acuerdo a los rsultados de las consultas anteriores. No te olvides que el parser trabaja estadísticamente.
Y precisamente por ese nivel de análisis que hace, el hecho de que haya una cardianlidad elevada entre diferentes valores, impacta en el mayor o menor tiempo en que una consulta se ejecuta.
Yo te sugeriría que antes de seguir adelante, primero debes depurar las tablas para suprimir los duplicados, porque eso puede estar causando enorme redundancia, que se refleja en una mala performance de la consulta.

[xinxan22]

Entonces, al utilizar "DATE" no hace trabajar más el MySql ?

En cuanto elimine la redundancia quitaré ese GROUP BY.

Por otro lado, ahora estoy usando MyIsam, des de que hice el cambio me está funcionando perfectamente rápido.

Lo mantengo o vuelvo a Innodb, porque realmente me he dado cuenta que en esa tabla no necesito la relación del id_tabla2 (aunque tener la integridad referencial no va mal..)


Bueno, muchas gracias por todo :)