Influencer l’optimiseur de MySQL

janvier 29, 2009

Il est possible d’influencer l’optimiseur pour qu’il choisisse d’utiliser ou de ne pas utiliser un index particulier. Les clauses à placer dans votre requête SELECT sont les suivantes:

USE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas si l’index est plus couteux qu’un full table scan)

FORCE INDEX : utilise l’index passé en argument (MySQL ne l’utilisera pas …s’il ne peut pas l’utiliser 🙂 )

IGNORE INDEX : n’utilise pas l’index passé en argument

La plus part du temps, il se débrouille trés bien sans indications, mais parfois…

Dans cet exemple, j’utilise une table rental_daz inspirée de la table rental de la base de donnée sakila, voici sa structure:

Voici ma requête:

SELECT * FROM rental_daz WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR);

La commande EXPLAIN me permet de connaitre son plan d’exécution:

L’optimiseur voit l’index composite rental_date et l’utilise. Ça à l’air pas mal…

Voyons le coût de cette requête,grâce à au paramètre LAST_QUERY_COST :

Empêchons l’optimiseur d’utiliser l’index rental_date:

L’optimiseur n’utilise donc pas l’index (il ne le voit même pas). Un full table scan est donc effectué. C’est à priori plus coûteux que d’utiliser l’index. Regardons le coût de cette requêtes.

Malgré le full table scan, cette requête est moins coûteuse que celle qui utilise l’index !!!

Essayons de vérifier cela en durée. Le client mysqlslap est tout indiqué :

mysqlslap -uroot -proot  –create-schema=sakila -i50
-q »SELECT * FROM rental_daz WHERE  rental_date > SUBDATE(now(), INTERVAL  3 YEAR); »

mysqlslap -uroot -proot  –create-schema=sakila -i50
-q »SELECT * FROM rental_daz ignore index(rental_date) WHERE  rental_date > SUBDATE(now(), INTERVAL  3 YEAR); »

mysqlslap confirme bien que le full table scan est, dans ce cas précis, plus performant que la recherche indexée par intervalle. On se trouve bien dans un cas où l’optimiseur se trompe.

3 Responses to “Influencer l’optimiseur de MySQL”

  1. Je n’ai pas bien compris la conclusion. En quoi l’optimiseur se trompe t’il ? On arrive bien à un résultat inférieur sans utiliser l’index en utilisant Last_query_cost AINSI qu’avec mysqlslap.

  2. Bonjour Riplay,
    effectivement, on arrive bien à un résultat inférieur sans utiliser l’index, mais ce n’est pas ce plan qui est choisit par l’optimiseur, car il préfère utiliser l’index.
    Le plan d’exécution optimal est choisit, dans l’exemple, grâce à la clause ignore index(rental_date). a noter que ce plan est plus performant dans ce cas là. Avec une autre distribution des données ce ne serait peut être pas le cas !

  3. J’ai laissé reposer cette nuit, et j’ai compris. Merci.

Leave a Reply