Accéder au contenu principal

Requêtes UPDATE trop lentes- comment optimiser MySQL



Sur un de mes projets utilisant une base de données MySQL avec plusieurs millions d'enregistrements, j'ai constaté avec stupeur d'énormes lenteurs sur mes requêtes UPDATE.

En effet, mes requêtes s'effectuaient en boucle et le serveur MySQL explosait en consommation CPU.

Ma requête était aussi simple comme ci-dessous :

UPDATE  matable set cible='nouvelle_valeur';

Mais l'exécution de cette requête pouvait dépasser les 60 secondes sur ma table de plusieurs millions de lignes.

J'avais un serveur suffisamment dimensionné pour le projet avec 16Go de RAM sur un VPS. 

Après quelques analyses, il s'est avéré que le problème provenait de l'absence d'indexation du champs cible.

Phase 1 : diagnostique

Il est important de comprendre ce qui tourne ou qui consomment de la ressource pour comprendre pourquoi votre base de données devient lente.

Pour cela utiliser au passage une simple commande top, si vous êtes sur Debian, permettra de comprendre qui vous consomme le plus de la ressource.

Sur MySQL vous pouvez vérifier les requêtes qui tournent en prenant beaucoup de temps.

SHOW FULL PROCESSLIST

Vous verrez dans les résultats les requêtes, ainsi que le temps mis par chacune d'elle.


Phase 2 : correction 

Dans mon cas, c'étaient plusieurs centaines de requêtes updates qui tournaient et prenaient énormément de temps.

Il a fallut donc lancer une requête EXPLAIN pour voir comment ma requêtes se comporte réellement.

EXPLAIN select * from matable where cible='nouvelle_valeur';

Le résultat de cette requête m'a montré que le système parcourait les millions de lignes de ma table pour chaque exécution. J'avais donc l'explication sur les lenteurs de mes UPDATE. Zut !!!

Eh bien, la solution à ce problème est simplement de créer un index pour mon champs cible. Ainsi, le système n'aura plus à parcourir toutes les lignes de ma table, mais seulement une seule. Ceci rend l'exécution extrêmement plus rapide pour les centaines de requêtes en boucle.

ALTER TABLE matable ADD INDEX (cible);

Phase 3 : vérification

Une fois l'index est crée sur le champs cible, vous pouvez immédiatement voir une parfaite amélioration des vos requêtes UPDATE. refaite un EXPLAIN comme indiqué précédemment et le résultat montrera que le système ne parcours d'une seule ligne de votre table.

Enseignement :

Pour une table volumineuse, si vous devez mettre à jour des données à une grande fréquence, il est important de créer des index sur les champs de filtre. Il s'agit notamment des champs de la clause where. Ceci permettra de gagner en performance. Bien entendu, il existe bien d'autres aspects d'optimisations de la bases de données, prenez toujours le temps de poser un bon diagnostique afin de trouver la bonne correction à appliquer.






Commentaires

Posts les plus consultés de ce blog

Configuration d'un VPN IPsec sur Mikrotik

Introduction En supposant que vous avez déjà une bonne connaissance concernant la technologie VPN et des termes s'y afférents, je vais simplement présenter quelques étapes de configuration du VPN sur un mikrotik. C'est donc un coup de pouce pour ceux qui débutent sur les technologie Mikrotik. Je me limiterai à l'utilisation des interfaces graphiques et pour la ligne de commande, je reste toujours disponible pour plus de détails. Ce document ne s'étend pas sur des détail liés à l'utilisation d'un routeur/firewall Mikrotik. Pour plus de détails dans ce sens, je vous invite à visiter le site de Mikrotik www.mikrotik.com Environnement requis :  Windows (pour ce tutoriel) et système Unix (non pris en charge dans ce tutoriel). Architecture : Tout le long de ce tutoriel, nous allons considérer que les deux sites distants sont équipés chacun d'un routeur Mikrotik. Toutefois, au cas où l'un des sites aura un autre routeur (Cisco pa...

Du centre d'appel à un centre de contact unifié, les enjeux ?

Longtemps considérées comme des moulins à parole, les centres d'appels suivent fortement l'évolution technologique et les besoins des clients. Les entreprises exerçant dans ce secteurs sont intermédiaire entre le clients distant et le donneur d'ordre. Cependant, nous connaissons depuis quelques années un grand boom dans l'apparition de nouveaux canaux de communication utilisés par les clients. Ainsi, pour rester compétitif et répondre efficacement au besoin des clients, les centres d'appels doivent se reformer, innover et s'adapter pour progressivement devenir des véritables centre de contacts. Particularité d'un centre d'appel Un centre d'appel axe tout son métier dans la gestion de la relation client en utilisant comme canal principal le téléphone. Cela peut être fait par l'utilisation des lignes téléphoniques classiques, des liaisons louées ou la téléphonie IP. En fonction de la taille, et de la solution envisagée, l'infrastructure p...

Problème de transport "Unknow Transports" et TLS liés à la version de socket.io sur AWS

J'utilise Socket.io depuis quelques années comme serveur pour des flux bidirectionnels en temps réels. Je me croyais suffisamment dans la création des instances socket.io jusqu'à ce que je me retrouve à boucler depuis plusieurs jours pour monter un nouveau serveur sur AWS. En effet, j'ai procédé à la création d'un nouvel EC2 dédié pour l'hébergement de mon serveur socket.io. J'ai installé un disto debian, installé toutes les dépendances ainsi qu'apache2 et cerbot pour du TLS. J'ai réservé avec confiance mon IP elastic.  J'ai installé bien entendu nodejs, npm et bien sure : socketio. (début du problème). Je croyais à ce niveau que l'installation de socketio via la commande npm install socketio installerait la dernière version (la dernière version au moment de l'écriture de ce message etait la 4.7.5). C'était ma première erreur. Mais npm a plutôt installé une ancienne version, la 1.7.x. Sans me rendre compte de ce fait, j'ai tranquillem...