No SO, alguém perguntou recentemente Por que o ORDER BY não está usando o índice?
A situação envolvia uma tabela InnoDB simples no MySQL com três colunas e 10 mil linhas. Uma das colunas, um número inteiro, foi indexada - e o OP procurou recuperar toda a tabela classificada nessa coluna:
SELECT * FROM person ORDER BY age
Ele anexou EXPLAINa saída mostrando que essa consulta foi resolvida com um filesort(em vez do índice) e perguntou por que isso aconteceria.
Apesar da dica que faz FORCE INDEX FOR ORDER BY (age) com que o índice seja usado , alguém respondeu (com comentários de apoio/votos positivos de outros) que um índice só é usado para classificação quando todas as colunas selecionadas são lidas do índice (ou seja, como normalmente seria indicado por Using indexna Extracoluna de EXPLAINsaída). Posteriormente, foi dada uma explicação de que percorrer o índice e, em seguida, buscar colunas da tabela resulta em E/S aleatória, que o MySQL considera mais caro do que um arquivo filesort.
Isso parece ir contra o capítulo do manual sobre ORDER BYOtimização , que não apenas transmite a forte impressão de que a satisfação ORDER BYde um índice é preferível a realizar uma classificação adicional (na verdade, filesorté uma combinação de quicksort e mergesort e , portanto, deve ter um limite inferior de ; enquanto percorrer o índice em ordem e procurar na tabela deveria ser - então isso faz todo o sentido), mas também deixa de mencionar essa suposta "otimização" ao mesmo tempo em que afirma:Ω(nlog n)O(n)
As consultas a seguir usam o índice para resolver a
ORDER BYpeça:SELECT * FROM t1 ORDER BY key_part1,key_part2,... ;
Na minha leitura, esse é precisamente o caso nesta situação (ainda assim o índice não estava sendo usado sem uma dica explícita).
Minhas perguntas são:
É realmente necessário que todas as colunas selecionadas sejam indexadas para que o MySQL opte por usar o índice?
Em caso afirmativo, onde isso está documentado (se houver)?
Se não, o que estava acontecendo aqui?