A tabela em questão era uma tabela de rollup / agregação.
Então não é apenas bom, é "certo".
E cheira a uma tabela Resumo, pois começa com day
.
Você tem alguns índices secundários? Lembre-se de que, se você estiver usando o InnoDB, o restante das colunas PRIMARY KEY será alinhado no final do índice secundário. Novamente, isso não é necessariamente um problema.
100 milhões de linhas é muito para um rollup. Parece que a mesa é muito refinada. Ou seja, talvez em vez disso, se (data, a, b, c, d) você tiver quatro rollups com PKs como (data, a, b, c), (data, b, c, d), (data, c, d, a), (data, d, a, b) (ou algumas combinações adequadas). Ao fazer isso, cada um pode ter apenas 10 milhões de linhas, tornando os relatórios ainda mais rápidos e tendo quase tanta flexibilidade no relatório.
Ou talvez mude para (semana, a, b, c, d), levando a talvez apenas 14 milhões de linhas. (Provavelmente mais.)
Usando PARTITION para facilitar a poda --- ingestão de alta velocidade --- dicas do Data Warehouse --- tabelas de resumo . Eles resumem muitas das técnicas que desenvolvi em vários projetos de DW. Como você pode inferir, cada projeto é diferente. O número "típico" de tabelas de resumo (na minha experiência) é 3-7. O destino na compactação é 10 linhas de fatos -> 1 linha de resumo. (Isso pode ser uma 'mediana'.) Em um caso raro, resumi uma tabela Resumo. Em outro caso raro, particionei uma tabela Resumo com bons resultados; geralmente as tabelas de resumo são pequenas o suficiente para serem rápidas o suficiente para acesso direto a partir da interface do usuário.