Optimizacion de configuración servidor MySQL 5.5

[combuilder]

Buenas.

Tengo un servidor MySQL 5.5 y se me plantean varias (muchas) dudas sobre cómo mejorar el rendimiento de la base de datos.

La base de datos más gorda que tengo ocupará unos 5 Gb, estando el 99% de dicha información en una tabla donde recojo datos de parámetros por fechas.

Las consultas SELECT se hacen eternas.

Estoy usando la configuración por defecto, así que me gustaría saber qué me aconsejais para mejorar el rendimiento.

Un saludo de antemano.

[combuilder]

Nadie puede echarme un cable?

[gnzsoloyo]

Las consultas SELECT se hacen eternas.

Las consultas pueden ser "eternas" incluso con excelentes configuraciones de servidor.
¿Has probado optimizarlas de otras formas?
¿Cómo son esas consultas "eternas", qué sintaxis tienen?

[combuilder]

Las consultas son así:

Código SQL:

SELECT * FROM Datos WHERE DATE(fecha) = '20110101' AND idinstalacioninversor = 1
 

La tabla es así:

Código MySQL:

CREATE TABLE `datos` (
    `iddato` INT(11) NOT NULL AUTO_INCREMENT,
    `fecha` DATETIME NULL DEFAULT NULL,
    `horanumero` DECIMAL(10,3) NULL DEFAULT '0.000',
    `idparametro` INT(11) NOT NULL,
    `idinstalacioninversor` INT(11) NOT NULL,
    `valor` DOUBLE NULL DEFAULT NULL,
    `anulado` TINYINT(1) NOT NULL DEFAULT '0',
    `actualizado` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    PRIMARY KEY (`iddato`),
    INDEX `fecha` (`fecha`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB;
 

[gnzsoloyo]

Vamos por partes:
1) Las consultas que usan "*" para obtener los campos usualmente son las más ineficientes de todas, porque traen todo, incluso campos que no se usarán.

2) Además, habitualmente no hacen uso de los índices secundarios, porque al traer la PK y siendo esta prioritaria en el orden (por ubicación de la columna), el aprovechamiento del índice de fecha es inexistente.

3) Crear un índice sobre un sólo campo, sin mas datos, puede volverse ineficiente, porque si bien la lectura podría acelerarse un poco, el WHERE no es optimizable, y se aplica una vez leído todo, por lo cual no le estas agregando una verdadera optimización al hacer la consulta.

4) Si vas a crear un índice secundario, usa principalmente un conjunto de datos que puedas necesitar en todas las ocasiones, o que sea crítico para la consulta. Algo como usar de clave de indice, la fecha, hora y idinstalacioninversor, podría ser mejor que sólo la fecha.

5) Una cosa que optimiza mucho es llamar a los campos que realmente vas a necesitar, y no a todos. En los sistemas complejos o de muchos datos (trabajo en uno de ellos), traer el listado completo de clientes con todos sus datos podría demandar mucho tiempo. En vez de eso se traen cuatro datos (la PK entre ellos), y luego con sólo la PK se invocan el resto de los que se necesitan. Eso ahorra ingentes cantidades de memoria, procesamiento y transmisión de datos, y le agrega un extra a la aplicación. Hacer las dos llamadas le lelva al sistema más de cien veces menos tiempo que traer todo la primera vez.

Hay oros puntos, pero la muestra que posteaste no permite darte mas consejor.
¿Tienes alguna otra consulta un poco más elaborado que esto sacado de manual? Digo algo verdaderamente lento, con JOINs o subconsultas.

Postea algo que realmente te esté trayendo problemas.

[combuilder]

Gracias por tus consejos.

Realmente tengo para trabajar un buen rato siguiendo todo lo que me has comentado.

Yo pensaba que, además, era importante configurar el servidor para facilitar el trabajo con grandes (en volumen) bases de datos, pero veo que antes habría que mejorara otras cosas!