Les progs de BD traitent ce genre de requêtes en prenant la selection du 1er index existant après le where , puis en testant ligne par ligne les autres conditions. L'auteur de la requête peut en tirer profit s'il sait utiliser l'index le plus restrictif en premier. Ce n'est pas toujours possible surtout quand les requêtes sont construites d'après un formulaire multi-options.
Slowsql est simplement la table des logs slow-sql.log de Mysql. Ces logs rapportent le cardinal du 1er index ( ici 15000 ). Mais ils ne disent pas l'effort que Mysql a fait pour analyser cet index et en extraire le tas de 15000. Cet effort est loin d'être négligeable. Il dépend de la répétitivité des index. Là, le prog de BD ne dispose pas , du moins en INNODB et MYISAM, de compteurs tenus à jour en temps réel. Comme il faut les calculer, il se contente donc du 1er. Statistiquement, dans les applis de type site web, n'utiliser qu'un index est plus efficace. Les caches-mémoires et les grosses ressources allègent la charge jusqu'à la rendre acceptable dans tous les cas.
On peut le regretter mais si on fournit au prog de BD un long algo, il y passera beaucoup de temps. Donc, évitez cette requête si son intérêt est mineur ou bien alors dessinez une autre base avec assez de résultats intermédiaires pour que la recherche pointe directement vers le plus petit paquet.
Il y a ici une première modification simple efficace qui consiste à créer un index multicolonnes col1,col2,col3. Il sera utilisé en priorité.
Dans des cas plus compliqués, il ne faut pas hésiter à ajouter et tenir à jour des colonnes rendant directement les résultats escomptés après les where. C'est d'ailleurs la seule façon de faire lorsque la condition ressemble à
select * from table where col1+col2 = 5 and col3=18
Pour une efficacité maximale , il faudrait créer une colonne col4 qui vaut toujours concat(col1+col2 , séparateur , col3 ) et en faire un index.
Si le séparateur choisi est '/' , cela donnerait cette nouvelle requête plus rapide :
select * from table where col4 = '5/18'
Pour une approche totale des colonnes de calcul intermédiaire, il ne faut pas manquer la page sur les triggers dans la documentation mysql
