Para realmente dar uma resposta, seria útil ver se você já possui índices existentes, mas ...
Tudo isso supondo que a tabela 't' exista e você precise adicionar um índice e atualmente tenha apenas um único índice em sua chave primária ou nenhum índice.
Um índice de cobertura para a consulta fornecerá o melhor desempenho para suas necessidades, mas com qualquer índice você sacrifica alguma velocidade de inserção. O quanto esse sacrifício importa depende do perfil do seu aplicativo. Se você lê principalmente a partir da mesa, não importa muito. Se você tiver apenas alguns índices, mesmo uma carga de gravação moderada não será importante. Espaço de armazenamento limitado para suas mesas também pode entrar em jogo... Você precisa fazer a avaliação final da troca e se é perceptível. A coisa boa é que é bastante um sucesso constante. Normalmente, adicionar um índice não diminui exponencialmente suas inserções, apenas linearmente.
Independentemente disso, aqui estão suas opções para o melhor desempenho selecionado:
- Se c3 for sua chave primária para a tabela t, você não poderá fazer nada melhor na consulta para torná-la mais rápida com um índice.
-
Assumindo que c1 é sua chave primária t:
ALTER TABLE t ADD INDEX covering_index (c3,c2); -
Se c1 não for seu pk (e nem c2), use isto:
ALTER TABLE t ADD INDEX covering_index (c3,c2,c1); -
Se c2 for o seu PK, use isso:
ALTER TABLE t ADD INDEX covering_index (c3,c1); -
Se o espaço no disco ou a velocidade de inserção for um problema, você pode optar por fazer um índice de pontos. Você sacrificará algum desempenho, mas se você for muito pesado, pode ser a opção certa:
ALTER TABLE t ADD INDEX a_point_index (c3);
