Você está apenas pedindo duas colunas em sua consulta, então os índices podem/devem ir para lá:
- DataHora
- Tempo de carregamento
Outra maneira de acelerar sua consulta pode ser dividir o campo DateTime em dois:data e hora.
Dessa forma, o db pode agrupar diretamente no campo de data em vez de calcular DATE(...).
EDITADO:
Se você preferir usar um gatilho, crie uma nova coluna (DATE) e chame-a de newdate , e tente com isso (não posso tentar agora para ver se está correto):
CREATE TRIGGER upd_check BEFORE INSERT ON SpeedMonitor
FOR EACH ROW
BEGIN
SET NEW.newdate=DATE(NEW.DateTime);
END
EDITADO NOVAMENTE:
Acabei de criar um banco de dados com a mesma tabela speedmonitor preenchida com cerca de 900.000 registros.
Então executo a consulta S
ELECT newdate,AVG(LoadTime) loadtime FROM speedmonitor GROUP BY newdate e demorou cerca de 100s!!
Removendo o índice no campo newdate (e limpando o cache usando RESET QUERY CACHE e FLUSH TABLES ), a mesma consulta levou 0,6s!!!
Só para comparação:query SELECT DATE(DateTime),AVG(LoadTime) loadtime FROM speedmonitor GROUP BY DATE(DateTime) levou 0,9s.
Então suponho que o índice em newdate não seja bom:remova-o.
Vou adicionar o máximo de registros que puder agora e testar duas consultas novamente.
EDIÇÃO FINAL:
Removendo índices nas colunas newdate e DateTime, com 8 milhões de registros na tabela speedmonitor, aqui estão os resultados:
- selecionar e agrupar na coluna newdate:7,5s
- selecionar e agrupar no campo DATE(DateTime):13,7s
Eu acho que é uma boa aceleração.
O tempo é gasto executando a consulta dentro do prompt de comando do mysql.
