Nous allons aujourd’hui traiter d’optimisation MySQL, en nous penchant sur le cas des alias de table. Ceux-ci ont-ils un réel impact sur les performances de nos requêtes ? C’est ce que nous allons voir dans ce billet.

Lorsque vous écrivez une requête SQL, il est possible de spécifier un alias au nom des tables que vous utilisez. Cela permet d’utiliser plusieurs champs portant le même nom dans des tables différentes tout en réduisant le nombre de caractères de votre requête. Un exemple sera bien plus parlant qu’un long discours :

Cependant, on peut se demander si ces alias ont un impact au niveau des performances de ces requêtes. On pourrait supposer que les alias de tables sont favorables aux performances. Mais qu’en est-il réellement ?

On spécifie explicitement au serveur le nom des tables dans lesquelles il doit rechercher le champ spécifié. Ainsi, il n’a pas à le déterminer lui-même, en parcourant la structure de toutes les tables présentes dans la requête. Ce qui pourrait nous laisser croire que l’utilisation des alias optimise nos requêtes. Vérifions donc notre théorie.

Pour ce faire, effectuons quelques tests d’exécution de requête sur une et deux tables, en faisant varier la présence d’alias et le moteur de bases de données. On obtient les résultats suivants (chiffre moyen basé sur l’exécution de 10.000 requêtes sur le même serveur de développement) :

InnoDB :

Une table, sans alias : 4.358 ms
Une table, avec alias : 4.382 ms
Deux tables, sans alias : 5.485 ms
Deux tables, avec alias : 5.421 ms

MyISAM :

Une table, sans alias : 4.488 ms
Une table, avec alias : 4.449 ms
Deux tables, sans alias : 5.376 ms
Deux tables, avec alias : 5.406 ms

Ainsi, comme nous pouvons le constater, les alias de tables n’ont aucun impact sur les performances. Cependant, ils permettent d’accroître grandement la lisibilité de vos requêtes, ce qui au final, accroît tout de même votre productivité en tant que développeur. La mort des alias n’est donc pas encore pour aujourd’hui. ;)

Lors de l’implémentation d’un script d’import massif d’adresses emails (environ 120.000 adresses), je me suis buté à une lenteur non négligeable de mon script. Plus de deux heures pour effectuer l’import. Je ne pouvais pas me permettre de laisser une telle longueur d’exécution pour mon ego personnel mes clients. :p

Après avoir essayé d’optimiser un maximum le code, je n’ai pas réussi à optimiser énormément le script. Je me suis donc penché du côté de la base de données. Je me suis donc amusé à modifier le moteur de ma table. Plusieurs choix m’étaient possibles, mais seuls deux me parlaient réellement, suite à la lecture de différents articles et à mon expérience personnelle : InnoDB et MyISAM.

InnoDB est un moteur de recherche prenant en charge les contraintes de clefs étrangères (ce qui me fait l’utilier le plus souvent), les transactions avec commit et rollback. MyISAM lui n’intègre pas toutes ses vérifications. Il est donc, en théorie, plus rapide. Il est d’ailleurs plebiscité pour les grosses requêtes de type SELECT. Cela ne nous intéresse pas dans notre cas (uniquement des INSERT). Qu’en est-il donc de ce changement de moteur ?

Pour faire mes tests, je me suis basé sur l’insertion de 500 enregistrements. Voici les temps moyens d’exécutions :

InnoDB :	41.4224 s
MyISAM :	0.1716 s

On constate donc que MyISAM est bien plus rapide qu’InnoDB. Moralité : employer MyISAM si aucune fonctionnalité avancée de MySQL ne doit être utilisée. Dans mon cas, cela a allégé la durée d’exécution de script : de deux heures, je suis passé à une minute. D’où un gain merveilleux. Et des clients satisfaits. ;)

En PHP, il existe de nombreuses fonctions. Tellement nombreuses que certaines se révèlent redondantes. Parfois avec des performances différentes. Nous allons étudier aujourd’hui les différentes méthodes nous permettant de caster (changer le type) de nos variables.

Pour ce faire, nous nous baserons sur la conversion d’un nombre réel (float) grâce à l’utilisation de trois méthodes :

1. floatvar
2. Simple casting : (float)
3. settype

Pour faire ces tests, je me suis basé sur le code suivant :

Il suffit ensuite de diviser les différentes moyennes par le nombre d’occurences, et on tombe sur la durée moyenne d’exécution du cast.

Afin d’obtenir des tests significatifs en statistiques, il est important de se baser sur une population la plus vaste possible. C’est pourquoi nous effectuons 10.000.000 (oui, dix millions !) de tests. Nous pourrions aller plus loin, mais il a déjà fallu mettre en place une directive set_time_limit pour achever tout cela. ;)

Les résultats, sans plus attendre…

floatval	2.141 µs
(float)	1.87 µs
settype	2.387 µs

Ainsi, nous voyons que le casting direct est 14 % plus rapide par rapport à floatval. Comme quoi il serait grand temps de faire un peu de ménage dans les fonctions PHP : fonctions redondantes, pas optimisées, etc… ;)