A diferença no desempenho é possivelmente devido a e.id_dernier_fichier estar no índice usado para o JOIN, mas e.codega não estar naquilo índice.

Sem uma definição completa de ambas as tabelas e de todos os seus índices, não é possível dizer com certeza. Além disso, incluir os dois EXPLAIN PLANs para as duas consultas ajudaria.




Por enquanto, no entanto, posso detalhar algumas coisas...

Se um INDEX for CLUSTERED (isso também se aplica a PRIMARY KEYs), os dados serão armazenados fisicamente na ordem do INDEX. Isso significa que saber que você deseja posição x no ÍNDICE também significa implicitamente que você deseja posição x na mesa.

Se o INDEX não estiver agrupado, no entanto, o INDEX está apenas fornecendo uma pesquisa para você. Efetivamente dizendo posição x no ÍNDICE corresponde à posição y na mesa.

A importância aqui é ao acessar campos não especificados no INDEX. Fazer isso significa que você realmente precisa ir até a TABELA para obter os dados. No caso de um CLUSTERED INDEX, você já está lá, a sobrecarga de encontrar esse campo é bem baixa. Se o INDEX não estiver agrupado, no entanto, você terá que JOIN the TABLE to the INDEX e, em seguida, encontrar o campo em que está interessado.




Observação; Ter um índice composto em (id_dernier_fichier, codega) é muito diferente de ter um índice apenas em (id_dernier_fichier) e um índice separado em apenas (codega) .




No caso da sua consulta, acho que você não precisa alterar o código. Mas você pode beneficiar da alteração dos índices.

Você menciona que deseja acessar muitos Campos. Colocar todos esses campos em um índice composto provavelmente não é a melhor solução. Em vez disso, você pode querer criar um CLUSTERED INDEX em (id_dernier_fichier) . Isso significa que, uma vez localizado o *id_dernier_fichier*, você já está no lugar certo para obter todos os outros campos também.




EDITAR Observação sobre MySQL e ÍNDICES CLUSTERED

13.2.10.1. Índices Agrupados e Secundários

Cada tabela InnoDB tem um índice especial chamado índice clusterizado onde os dados das linhas são armazenados:

• Se você definir uma PRIMARY KEY em sua tabela, o InnoDB a usará como o índice clusterizado.
• Se você não definir uma PRIMARY KEY para sua tabela, o MySQL escolhe o primeiro índice UNIQUE que tem apenas colunas NOT NULL como chave primária e o InnoDB o usa como índice clusterizado.
• Se a tabela não tiver PRIMARY KEY ou índice UNIQUE adequado, o InnoDB gera internamente um índice clusterizado oculto em uma coluna sintética contendo valores de ID de linha. As linhas são ordenadas pelo ID que o InnoDB atribui às linhas dessa tabela. O ID da linha é um campo de 6 bytes que aumenta monotonicamente à medida que novas linhas são inseridas. Assim, as linhas ordenadas pelo ID da linha estão fisicamente na ordem de inserção.