Indexation MySQL et utilisation du tri de fichiers

Dans votre première requête, le ORDER BY est fait en utilisant le views_point INDEX, car il a été utilisé dans la partie WHERE de la requête et donc dans MySQL peut être utilisé pour le tri.

Dans la deuxième requête, MySQL résout la partie WHERE en utilisant un index différent, listing_pcs . Cela ne peut pas être utilisé pour satisfaire la condition ORDER BY. MySQL utilise filesort à la place, qui est la meilleure option si un index ne peut pas être utilisé.

MySQL n'utilise des index pour trier que si l'index est le même que celui utilisé dans la condition WHERE. C'est ce que le manuel signifie par :

Alors que pouvez-vous faire :

Essayez d'augmenter votre sort_buffer_size config pour rendre le tri de fichiers aussi efficace que possible. Les résultats volumineux qui sont trop volumineux pour le tampon de tri obligent MySQL à décomposer le tri en morceaux, ce qui est plus lent.
Forcez MySQL à choisir un index différent. Il convient de noter que différentes versions de MySQL choisissent les index par défaut différemment. La version 5.1, par exemple, est assez mauvaise car l'optimiseur de requête a été largement réécrit pour cette version et a nécessité beaucoup de raffinement. La version 5.6 est plutôt bonne.
```
SELECT *
FROM listings
FORCE INDEX (views_point)
WHERE (`publishedon_hourly` BETWEEN
       UNIX_TIMESTAMP( '2015-09-5 00:00:00' )
       AND UNIX_TIMESTAMP( '2015-09-5 12:00:00' ))
  AND (published =1)
  AND cat_id IN ( 1, 2, 3, 4, 5 )
ORDER BY `views_point` DESC
LIMIT 10
```