http://dasini.net/blog/presentations/?#presentation_mysql51

PDF à télécharger

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.

mysqlslap : un utilitaire de test de charge et de performance

Disponible depuis MySQL 5.1.4, mysqlslap permet d’effectuer des tests de stress et de charge sur votre serveur MySQL. Vous pourrez alors tester les performances de votre SGBDR préféré, après, par exemple, une nouvelle installation, un changement d’architecture ou après avoir modifié des paramètres de configuration.

Créé pour devenir le meilleur ami des administrateurs de bases de données et des développeurs, le client mysqlslap envoie des requêtes au serveur MySQL en créant plusieurs connexions simultanées. A la fin de la simulation, un rapport de diagnostic est crée sur la sortie standard. Vous avez aussi la possibilité de l’écrire dans un fichier au format CSV utilisable directement avec Calc d’OpenOffice ou Excel de Microsoft.

Exemple d’utilisation de mysqlslap avec les options suivantes :

• user, password, socket : autentification classique d’un client MySQL,
• concurrency : nombre de clients effectuant simultanément une requête SELECT,
• iterations : nombre d’itérations du test à faire,
• number-of-queries : nombre total de requêtes effectuées lors du test,
• engine : moteur(s) à utiliser,
• auto-generate-sql : mysqlslap génère automatiquement un jeu de tests,
• number-int-cols : nombre de colonnes de type INT à créer,
• number-char-cols : nombre de colonnes de type CHAR à créer,
• auto-generate-sql-load-type : permet de spécifier le type de requêtes (lecture, insertion, lecture sur la clé primaire, mise à jour ou mixte)

Tests de performances avec des tables MyISAM et innoDB:

shell> mysqlslap --user=daz --password --socket=/tmp/mysql51.sock
--concurrency=1,100   --iterations=10  --number-of-queries=1000
--engine=myisam,innodb   --auto-generate-sql  --number-int-cols=2
--number-char-cols=3   --auto-generate-sql-load-type=mixed


Benchmark
   Running for engine myisam
   Average number of seconds to run all queries: 1.576 seconds
   Minimum number of seconds to run all queries: 1.539 seconds
   Maximum number of seconds to run all queries: 1.631 seconds
   Number of clients running queries: 1
   Average number of queries per client: 1000
Benchmark
   Running for engine myisam
   Average number of seconds to run all queries: 1.792 seconds
   Minimum number of seconds to run all queries: 1.543 seconds
   Maximum number of seconds to run all queries: 2.107 seconds
   Number of clients running queries: 100
   Average number of queries per client: 10
Benchmark
   Running for engine innodb
   Average number of seconds to run all queries: 2.477 seconds
   Minimum number of seconds to run all queries: 2.430 seconds
   Maximum number of seconds to run all queries: 2.663 seconds
   Number of clients running queries: 1
   Average number of queries per client: 1000
Benchmark
   Running for engine innodb
   Average number of seconds to run all queries: 2.704 seconds
   Minimum number of seconds to run all queries: 0.725 seconds
   Maximum number of seconds to run all queries: 5.272 seconds
   Number of clients running queries: 100
   Average number of queries per client: 10

Conclusion

Toujours aussi performant, fiable et robuste, certes un peu moins simple à administrer mais tellement plus riche, cette nouvelle version de MySQL devrait faire le bonheur des administrateurs de bases de données et des développeurs. Nous espérons que cet article vous a mis l’eau à la bouche et vous donnons d’ors et déjà rendez-vous au prochain numéro pour explorer plus en détail le partitionnement de MySQL.

Les nouveautés de MySQL 5.1 — (part 1/5)