Eu corro a seguinte consulta no meu banco de dados:
SELECT e.id_dernier_fichier
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant
E a consulta é executada corretamente. Se eu modifico a consulta assim:
SELECT e.codega
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant
A consulta fica muito lenta! O problema é que eu quero selecionar muitas colunas na tabela eef, e a consulta pode levar até 1 minuto! Eu tentei diferentes modificações, mas nada funciona. Eu tenho índices no id_ * também no e.codega. A Enfants possui 9 mil linhas e a FichiersEnfants possui 20 mil linhas. Alguma sugestão ?
Aqui estão as informações solicitadas (desculpe não tê-las mostrado desde o começo):
Respostas:
2 para resposta № 1A diferença no desempenho é possivelmente devido a e.id_dernier_fichier estando no índice usado para o JOIN, mas e.codega não estando em aquele í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 elaborar algumas coisas ...
Se um ÍNDICE estiver CLUSTERED (isto também se aplica a PRIMARY KEYs), os dados são fisicamente armazenados na ordem do ÍNDICE. Isso significa que saber que você quer posição x no índice também implicitamente significa que você quer posição x na mesa.
Se o índice não está agrupado, no entanto, o índice está apenas fornecendo uma pesquisa para você. Efetivamente dizendo posição x no ÍNDICE corresponde a posição y na mesa.
A importância aqui é ao acessar campos nãoespecificado no ÍNDICE. Fazer isso significa que você precisa ir até o TABLE para obter os dados. No caso de um CLUSTERED INDEX, você já está lá, a sobrecarga de encontrar esse campo é muito baixa. Se o INDEX não estiver agrupado, no entanto, você terá que JUNTAR TABELA ao ÍNDICE, em seguida, encontrar o campo que você "re interessado em.
Nota; Ter um índice composto em (id_dernier_fichier, codega) é muito diferente de ter um índice em apenas (id_dernier_fichier) e um índice separado em apenas (codega).
No caso de sua consulta, eu não acho que você precise alterar o código. Mas você pode beneficiar de alterar os índices.
Você menciona que deseja acessar muitos Campos. Colocar todos esses campos em um índice composto não é, de maneira visível, a melhor solução. Em vez disso, você pode criar um CLUSTERED INDEX on (id_dernier_fichier). Isso significará que, uma vez localizado o * id_dernier_fichier *, você já estará no lugar certo para obter todos os outros campos também.
EDITAR Nota sobre os índices MySQL e CLUSTERED
13.2.10.1. Índices Clusterizados e Secundários
Toda tabela InnoDB possui 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 utilizará como o índice clusterizado.
- Se você não definir uma PRIMARY KEY para sua tabela, o MySQL selecionará o primeiro índice UNIQUE que tem apenas colunas NOT NULL como a chave primária e o InnoDB o utiliza como o índice clusterizado.
- Se a mesa não tiver PRIMARY KEY ou adequadaÍndice UNIQUE, 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 em tal 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 em ordem de inserção.