Isso se deve ao que chamo de regra dos 5% com base na população-chave (tupla cardinalidade).

Se você indexar uma tabela onde existe cardinalidade desigual, o MySQL Query Optimizer sempre escolherá o caminho de menor resistência.

EXEMPLO:Se uma tabela tem uma coluna de gênero, a cardinalidade é dois, M e F.

O que você indexa como uma coluna de gênero ??? Você essencialmente obtém duas listas vinculadas gigantes.

Se você carregar um milhão de linhas em uma tabela com uma coluna de gênero, poderá obter 50% M e 50% F.

Um índice se torna inútil durante a otimização de consulta se a cardinalidade de uma combinação de chaves (população de chaves como eu a expressei) for superior a 5% da contagem total da tabela.

Agora, com relação ao seu exemplo, por que os dois planos EXPLAIN diferentes ??? Meu palpite é o MySQL Query Optimizer e o InnoDB como uma equipe de tags.

No primeiro CREATE TABLE, a tabela e os índices são aproximadamente do mesmo tamanho, embora pequenos, então decidiu a favor do índice fazendo uma varredura de índice, não uma varredura completa da tabela . Lembre-se de que índices não exclusivos carregam a chave primária interna de cada linha (RowID) em suas entradas de índice, tornando os índices quase do mesmo tamanho que a própria tabela.

No segundo CREATE TABLE, devido à introdução de outra coluna, user, agora você faz o Query Optimizer ver um cenário completamente diferente:A tabela agora é maior que os índices . Assim, o Otimizador de Consultas tornou-se mais rigoroso em sua interpretação de como usar os índices disponíveis. Foi para a regra de 5% que mencionei antes. Essa regra falhou miseravelmente e o Query Optimizer decidiu a favor de uma verificação completa da tabela.