A primeira coisa a saber é que o MySQL usa apenas um índice por psuedo-SELECT (não instrução) - quando você visualiza a saída do SELECT usando EXPLAIN, você verá qual índice foi escolhido por. EXPLAIN só pode ser executado em SELECTS, então temos que assumir que um DELETE/UPDATE está usando o mesmo plano quando você troca a sintaxe por SELECT...
A maioria dos bancos de dados (os embutidos podem ser estranhos) que eu saiba suporta o uso de índices nas seguintes cláusulas:
- SELECIONAR
- JOIN (sintaxe ANSI-92)
- WHERE (porque há ANSI-89 e filtragem aqui)
- HAVING (WHERE equivalente, mas diferente de WHERE - permite o uso agregado sem precisar de subconsulta)
- ORENDER POR
Não estou 100% no GROUP BY, então estou omitindo por enquanto.
Em última análise, é a escolha do otimizador para o que usar com base em seu algoritmo e nas estatísticas que ele possui. Você pode usar a sintaxe ANALYZE TABLE para atualizar as estatísticas (periodicamente, não constantemente, por favor).
Adendo
O MySQL também limita a quantidade de espaço para alocar índices - 1.000 bytes para tabelas MyISAM e 767 bytes para tabelas InnoDB . Por causa do MySQL usar apenas um índice por psuedo-SELECT, cobrir índices (índices que incluem mais de uma coluna) é uma boa ideia, mas realmente se trata de testar a consulta mais comum e otimizar da melhor maneira possível. A prioridade de indexação deve ser:
- Chave primária (em algum lugar na v5, a criação de índice para o pk se tornou automática)
- Chaves estrangeiras (próximo candidato JOIN mais provável
- Critérios de filtragem (supondo que você tenha espaço)
