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:
12:14 daz$sakila> SHOW CREATE TABLE rental_daz\G
*************************** 1. row ***************************
Table: rental_daz
Create Table: CREATE TABLE `rental_daz` (
`rental_id` int(11) NOT NULL AUTO_INCREMENT,
`rental_date` datetime NOT NULL,
`inventory_id` mediumint(8) unsigned NOT NULL,
`customer_id` smallint(5) unsigned NOT NULL,
`return_date` datetime DEFAULT NULL,
`staff_id` tinyint(3) unsigned NOT NULL,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`rental_id`),
UNIQUE KEY `rental_date` (`rental_date`,`inventory_id`,`customer_id`),
KEY `idx_fk_inventory_id` (`inventory_id`),
KEY `idx_fk_customer_id` (`customer_id`),
KEY `idx_fk_staff_id` (`staff_id`)
) ENGINE=InnoDB AUTO_INCREMENT=16050 DEFAULT CHARSET=utf8
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:
12:14 daz$sakila> EXPLAIN SELECT * FROM rental_daz
WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental_daz
type: range
possible_keys: rental_date
key: rental_date
key_len: 8
ref: NULL
rows: 2744
Extra: Using where
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 :
12:19 daz$sakila> SHOW STATUS LIKE 'Last_query_cost'; +-----------------+-------------+ | Variable_name | Value | +-----------------+-------------+ | Last_query_cost | 3842.609000 | +-----------------+-------------+
Empêchons l’optimiseur d’utiliser l’index rental_date:
12:20 daz$sakila> EXPLAIN SELECT * FROM rental_daz IGNORE INDEX(rental_date)
WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: rental_daz
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 16298
Extra: Using where
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.
16:18 daz$sakila> SHOW STATUS LIKE 'Last_query_cost'; +-----------------+-------------+ | Variable_name | Value | +-----------------+-------------+ | Last_query_cost | 3356.599000 | +-----------------+-------------+
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); »
Benchmark
Average number of seconds to run all queries: 0.287 seconds
Minimum number of seconds to run all queries: 0.140 seconds
Maximum number of seconds to run all queries: 1.172 seconds
Number of clients running queries: 1
Average number of queries per client: 1
mysqlslap -uroot -proot –create-schema=sakila -i50
-q »SELECT * FROM rental_daz ignore index(rental_date) WHERE rental_date > SUBDATE(now(), INTERVAL 3 YEAR); »
Benchmark
Average number of seconds to run all queries: 0.167 seconds
Minimum number of seconds to run all queries: 0.078 seconds
Maximum number of seconds to run all queries: 1.094 seconds
Number of clients running queries: 1
Average number of queries per client: 1
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.
Tags: index, Last_query_cost, mysqlslap, optimiser