Ao chegar ao 'respeitável ', 2 milhões de linhas ainda é um tamanho relativamente pequeno para uma tabela. (E, portanto, um desempenho mais rápido é normalmente possível)

Como você descobriu, os curingas front-end são particularmente ineficientes e teremos que encontrar uma solução para isso se esse caso de uso for comum para seu aplicativo.

Pode ser que você não tenha o conjunto certo de índices . Antes de prosseguir, no entanto, gostaria de enfatizar que, embora os índices normalmente melhorem o desempenho do DBMS com instruções SELECT de todos os tipos, ele sistematicamente tem um efeito negativo no desempenho das operações "CUD" (ou seja, com o SQL CREATE/INSERT, UPDATE , verbos DELETE, ou seja, as consultas que escrevem para o banco de dados em vez de apenas ler a ele). Em alguns casos, o impacto negativo dos índices nas consultas de "gravação" pode ser muito significativo.

Minha razão para enfatizar particularmente a natureza ambivalente dos índices é que parece que seu aplicativo faz uma boa quantidade de coleta de dados como parte normal de sua operação, e você precisará observar a possível degradação à medida que as consultas INSERTs ficam mais lentas . Uma alternativa possível é realizar a coleta de dados em uma tabela/banco de dados relativamente pequena, com poucos ou nenhum índice, e importar regularmente os dados desse banco de dados de entrada para um banco de dados onde ocorre a mineração de dados real. (Depois de importadas, as linhas podem ser excluídas do "banco de dados de entrada", mantendo-o pequeno e rápido para sua função INSERT.)

Outra preocupação/questão é sobre a largura de uma linha na tabela de conversão (o número de colunas e a soma das larguras dessas colunas). O mau desempenho pode estar relacionado ao fato de as linhas serem muito largas, resultando em poucas linhas nos nós folha da tabela e, portanto, em uma estrutura de árvore mais profunda do que o necessário.

Voltando aos índices...
tendo em vista as poucas consultas na pergunta, parece que você poderia se beneficiar de um índice ip + note (um índice feito pelo menos com essas duas chaves nesta ordem). Uma análise completa da situação do índice e, francamente, uma possível revisão do esquema do banco de dados não pode ser feita aqui (informação insuficiente para um...), mas o processo geral para fazer isso é fazer a lista dos casos de uso mais comuns e para ver quais índices de banco de dados podem ajudar nesses casos. Pode-se obter informações sobre como determinadas consultas são tratadas, inicialmente ou após a adição de índices, com o comando mySQL EXPLAIN.

Normalização OU desmormalização (ou mesmo uma combinação de ambos!), muitas vezes é uma ideia viável para melhorar o desempenho durante as operações de mineração.