Ma base de données ralentit mon site. Doit-elle avoir son propre serveur ?

Votre boutique se charge bien en début de matinée, puis se traîne à l'heure du déjeuner. Le tableau de bord WordPress met quelques secondes à ouvrir un produit, et un test de vitesse vous donne un score correct avec une remarque vague sur le temps de réponse du serveur. Sur un forum, quelqu'un affirme que la base de données est en cause ; quelqu'un d'autre assure qu'un serveur plus gros réglera le problème.

Le guide sur les bases de données WordPress de DreamHost le souligne : les outils de vitesse en ligne n'ont pas accès à votre base de données. Un site peut donc obtenir un bon score tout en exécutant des requêtes lentes. Il vous faut un test qui regarde à l'intérieur de la page pendant sa construction. C'est ce que fait Query Monitor.

Nous allons procéder dans l'ordre : déterminer si MySQL est bien le maillon lent, corriger ce que vous pouvez sur votre serveur actuel, puis décider si un serveur MySQL privé en vaut la peine et ce qui change quand vos données déménagent.

Vérifiez que la lenteur vient de la base de données

Vous pouvez effectuer toutes les vérifications ci-dessous depuis votre panel et WordPress, sans droits d'administrateur sur le serveur MySQL, et aucune ne modifie votre site, à part l'installation d'un plugin.

1. Identifiez votre serveur MySQL et son emplacement

   Ouvrez la page MySQL Databases de votre panel et lisez le nom du serveur à côté de chaque base de données. Le guide de DreamHost sur les journaux de base de données explique ces noms : un nom commençant par iad1 désigne un serveur MySQL partagé, sql suivi d'un numéro un serveur MySQL privé, et ds un serveur dédié. Si le vôtre commence déjà par sql, vous êtes sur un serveur privé et les signes d'achat présentés plus bas ne vous concernent pas. Ouvrez ensuite la page Data Centers du panel. Vos serveurs web et MySQL doivent se trouver dans le même centre de données pour réduire la latence réseau ; si ce n'est pas le cas, le support peut les déplacer.

2. Installez Query Monitor et comparez deux chiffres

   Query Monitor est un plugin gratuit qui liste toutes les requêtes de base de données d'une page et les regroupe par plugin, thème ou cœur de WordPress. Connectez-vous en tant qu'administrateur et ouvrez une page qui vous semble lente. Le menu du plugin dans la barre d'outils d'administration affiche le temps de génération de la page et le temps total pris par les requêtes SQL, tous deux en secondes. Comparez-les. Si le temps des requêtes ne représente qu'une petite partie du temps de génération, c'est autre chose que la base de données qui ralentit la page, par exemple des appels HTTP ou le rendu des blocs.

3. Trouvez le plugin et les requêtes qui prennent ce temps

   Ouvrez le panneau Queries by Component. Il est trié par temps total : le plugin ou le thème qui passe le plus de temps dans la base de données apparaît en haut, et l'auteur du plugin conseille de commencer par là quand un site semble lent. Query Monitor signale une requête comme lente dès qu'elle dépasse 0,05 seconde. Il repère aussi les doublons, qui signifient généralement que du code exécute une requête dans une boucle alors qu'il pourrait l'exécuter une seule fois et mettre le résultat en cache.

4. Chargez la même page en heure creuse et en heure de pointe

   Query Monitor ne conserve aucun historique. Notez les chiffres. Chargez la page lente à un moment calme, puis à votre heure la plus chargée, et comparez le temps total des requêtes ainsi que la durée des mêmes requêtes lentes. L'article de DreamHost sur l'amélioration des performances de base de données cite les ralentissements aux pics de trafic parmi les signes que la base de données est le goulet d'étranglement, et recommande aussi de vérifier l'utilisation de votre serveur pendant ces pics.

5. Consultez votre graphique d'utilisation aux mêmes heures

   Avec l'hébergement web, la page Servers & Usage affiche sous forme de graphique le CPU, la RAM et le stockage, avec les niveaux Low, Medium ou High, sur le dernier jour, la dernière semaine ou les deux dernières semaines. Le guide d'utilisation du centre d'aide précise que le CPU et la RAM du serveur web sont partagés entre les comptes, mais que les graphiques ne montrent que l'utilisation de votre compte. Une valeur High désigne votre propre PHP et vos plugins. Une valeur normale vous indique que votre compte n'est pas le gros consommateur, mais elle ne vous dit pas à quel point le reste du serveur est chargé.

Associez maintenant ce que vous avez observé à une cause probable :

Ce que le MySQL partagé ne vous montre pas

Sur MySQL partagé, vous n'avez pas accès aux journaux du serveur, y compris les journaux des requêtes lentes, et le guide de DreamHost sur les journaux de base de données indique que le support ne peut pas non plus les récupérer pour vous. Votre utilisateur MySQL ne dispose pas non plus du privilège PROCESS : la liste des processus n'affiche donc que vos propres requêtes, et il ne peut pas exécuter SET GLOBAL pour modifier les réglages du serveur.

Le journal des requêtes lentes décrit dans le manuel de MySQL est donc hors de portée ici : il est désactivé par défaut, et seule une personne disposant des droits d'administrateur sur le serveur peut l'activer. Sa limite par défaut est de 10 secondes. Le même guide du centre d'aide précise que le support de DreamHost peut récupérer les journaux pour vous, sur demande, depuis un serveur MySQL privé. Sur un serveur dédié, vous avez vous-même accès aux fichiers de configuration de MySQL.

Corrigez d'abord le problème là où il se trouve

Toutes ces mesures fonctionnent avec votre offre actuelle, avant de payer quoi que ce soit.

Examinez les requêtes lentes avec EXPLAIN. Copiez une requête lente depuis Query Monitor. Placez EXPLAIN devant et exécutez-la dans phpMyAdmin. La documentation de MySQL sur l'instruction EXPLAIN explique comment celle-ci affiche le plan que MySQL va suivre, y compris les index qu'il lit, et EXPLAIN ANALYZE exécute la requête et indique sa durée réelle. Le MySQL partagé de DreamHost accorde le privilège INDEX : vous pouvez donc ajouter un index quand le plan montre que MySQL parcourt une table entière. Notez chaque index que vous ajoutez à une table WordPress ou WooCommerce, afin de vérifier qu'il est toujours là après les mises à jour.

EXPLAIN SELECT option_name FROM wp_options
WHERE autoload = 'yes' OR autoload = 'on';

Nettoyez les tables propres à WordPress. Les étapes de nettoyage de base de données WordPress de DreamHost s'exécutent en SSH avec WP-CLI. Elles suppriment les transients, optimisent les tables, réduisent les révisions d'articles et nettoient les tables postmeta et commentmeta. Vérifiez avant tout la taille de vos options autoload, car WordPress les charge à chaque requête ; en dessous d'environ 600 Ko, c'est bon pour la plupart des serveurs. Ces commandes sont tirées de cet article :

wp transient delete --all
wp db optimize
wp db query "SELECT SUM(LENGTH(option_value)/1048576) as 'Autoload(MB)' FROM $(wp config get table_prefix)options WHERE autoload='yes' or autoload='on';"

Les tables très fragmentées ralentissent les requêtes et peuvent provoquer l'expiration du délai du serveur web pendant qu'il attend une réponse. L'option Optimize table de phpMyAdmin supprime cette fragmentation, comme l'explique le guide de DreamHost sur les lenteurs.

Activez la mise en cache. La documentation de WordPress sur les performances présente la mise en cache comme le moyen le plus rapide d'améliorer les performances. Un plugin de cache de page sert les articles et les pages sous forme de fichiers statiques : la plupart des visites n'atteignent donc jamais MySQL. Ajoutez ensuite un cache d'objets.

Sur l'hébergement partagé, le centre d'aide de DreamHost documente le plugin Docket Cache comme cache d'objets persistant basé sur des fichiers, et OPcache, dont il a besoin, est déjà activé. Si vous préférez ne pas gérer la mise en cache du tout, l'hébergement WordPress avec mise en cache intégrée de DreamHost s'en charge au niveau du serveur.

Les réglages au niveau du serveur, comme la mémoire d'InnoDB, sont un chantier à part, traité dans notre article sur l'optimisation de MySQL sur un VPS.

Les signes que la base de données a besoin de son propre serveur

DreamHost présente MySQL partagé comme adapté aux bases de données optimisées et aux performances web standard, et MySQL VPS comme conçu pour les clients qui ont besoin d'une réponse plus rapide de la base de données ou qui ont dépassé les capacités de MySQL partagé. La page MySQL VPS nomme aussi la limite du partage dans sa FAQ : un serveur partagé peut entraîner des goulets d'étranglement en cas de trafic inhabituellement élevé.

Des requêtes lentes ne signifient pas à elles seules que MySQL partagé ne vous convient pas. N'envisagez un serveur privé qu'une fois les correctifs ci-dessus appliqués, si ces signes persistent malgré tout :

• Les mêmes requêtes sont plus lentes à votre heure de pointe. Vos notes Query Monitor, prises aux heures creuses et aux heures de pointe, montrent que les mêmes requêtes prennent nettement plus de temps quand le trafic est élevé, même après nettoyage et mise en cache.
• Les erreurs de connexion reviennent sans cesse alors que vous avez vérifié le nom d'hôte et que le support a contrôlé le serveur. Un MySQL VPS offre à vos bases de données des ressources qu'elles ne partagent avec aucun autre utilisateur. DreamHost ne publie pas de limite de connexions pour l'un ou l'autre type de serveur : nous ne pouvons donc pas vous donner de chiffre.
• Votre application a besoin de déclencheurs ou de procédures stockées. Selon le centre d'aide de DreamHost, vous ne pouvez pas créer de nouveaux déclencheurs sur MySQL partagé, où les procédures stockées sont indiquées comme indisponibles, alors qu'un MySQL VPS prend en charge les deux.
• Vous avez besoin des journaux MySQL pour déboguer. Selon le centre d'aide de DreamHost, le support peut les récupérer depuis un serveur MySQL privé.

Si aucun de ces cas ne s'applique à vous, ne changez rien. Une réponse publiée sur Stack Overflow en 2009 plaide pour le statu quo :

La réponse la mieux notée du même fil, avec 188 votes, défend la position inverse pour des raisons d'évolutivité et de performances. Appuyez-vous sur vos propres chiffres aux heures de pointe pour trancher.

Ce qui change quand la base de données déménage

Si vous craignez qu'une base de données distante ajoute un saut réseau, sachez que votre site en a déjà un. La présentation de MySQL de DreamHost indique où tourne chaque type de serveur MySQL :

C'est pourquoi le centre d'aide de DreamHost demande aux clients de ne jamais utiliser localhost comme hôte de base de données. Ajouter un MySQL VPS change uniquement l'emplacement de la base de données, et votre site continue d'y accéder par le réseau. Les témoignages de forums sur les bases de données distantes concernent d'autres configurations. Dans un fil Server Fault, un site hébergé aux États-Unis utilisait une base de données située en Asie et répondait très lentement, jusqu'à ce que la base soit déplacée sur un serveur local. C'est la distance qui causait ce délai, et c'est pourquoi la vérification du centre de données figure en premier dans les étapes ci-dessus.

Le déplacement lui-même se lance depuis le panel :

1. Sauvegardez chaque base de données
   Commencez par exporter une copie de chaque base de données.
2. Ajoutez un MySQL VPS depuis le panel

   Si votre compte comporte déjà un VPS, utilisez Add Service+ sur la page Servers & Usage. Sinon, ouvrez la page MySQL Databases et cliquez sur Turn on a MySQL VPS!. Les étapes de DreamHost pour ajouter un MySQL VPS couvrent les deux cas. La mise en service peut prendre quelques heures.

3. Choisissez une nuit calme pour la migration

   Selon le centre d'aide, DreamHost déplace toutes les bases de données de votre compte vers le nouveau serveur à minuit, heure du Pacifique, et le panel affiche l'opération comme une fusion. Il ne précise pas si votre site est indisponible pendant le déplacement, ni combien de temps celui-ci dure. Ajoutez le serveur un jour où minuit, heure du Pacifique, tombe à une heure creuse pour vos visiteurs, et interrogez le support au préalable si vous avez besoin d'une réponse ferme.

4. Repérez les bases restées en arrière

   Certaines bases de données peuvent se retrouver réparties entre l'ancien serveur partagé et le nouveau. Le bouton Move my databases! de la page MySQL Databases les rassemble alors au même endroit.

5. Vérifiez le nom d'hôte et testez à nouveau

   Ouvrez la page MySQL Databases et comparez le nom d'hôte affiché pour chaque base de données avec DB_HOST dans votre fichier de configuration. S'ils diffèrent, modifiez DB_HOST pour qu'il corresponde au panel. Un nom d'hôte nouvellement ajouté peut mettre jusqu'à 4 heures à fonctionner, car les noms d'hôte de bases de données sont des noms DNS. Chargez ensuite vos pages lentes aux mêmes heures creuses et de pointe, puis comparez les temps avec vos notes.

Après la migration, certaines choses fonctionnent différemment :

• Vous n'avez toujours pas d'accès root ni SSH. MySQL VPS est géré : DreamHost se charge de la maintenance, des correctifs de sécurité et des mises à jour du système d'exploitation, et c'est DreamHost qui définit les paramètres MySQL. Si vous avez besoin des fichiers de configuration, ou si votre application échange de gros volumes de données avec MySQL, DreamHost vous oriente vers un serveur dédié, où MySQL tourne sur la même machine.
• La RAM peut augmenter plus tard. Vous pouvez augmenter la RAM depuis le panel à tout moment, et le centre d'aide indique que vous recevez un crédit au prorata pour l'ancienne offre.
• Vous pouvez vérifier si vos données tiennent en mémoire. Exécutez SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'; et calculez 1 moins Innodb_buffer_pool_reads divisé par Innodb_buffer_pool_read_requests. Sur un serveur qui n'héberge que vos bases de données, vous obtenez la part des lectures servies depuis la mémoire, soit le chiffre du tableau de dimensionnement ci-dessous. Sur notre MySQL de test, un utilisateur disposant de droits sur une seule base de données pouvait lire ces compteurs, mais pas SHOW ENGINE INNODB STATUS.
• Le retour en arrière est soumis à une limite de taille. Si vous n'avez pas de serveur dédié, chaque base de données du MySQL VPS doit faire moins de 3 Go avant que vous puissiez supprimer le serveur depuis le panel. Vous choisissez ensuite un serveur de destination, et DreamHost transfère vos données vers le serveur de bases de données partagé sous 24 heures.

Quelle option vous convient

Choisissez la voie qui correspond aux résultats de vos vérifications.

Si vous optez pour MySQL VPS, commencez par VPS business. La page de DreamHost le présente comme Conçu pour les petites entreprises, et la liste des offres du panel de DreamHost lui attribue 1 Go de RAM et 20 Go de stockage. VPS basic est l'offre inférieure. La page présente VPS basic comme Pour les sites nouveaux et de petite taille, ce qui convient à un petit site qui migre surtout pour les déclencheurs, les routines ou les journaux. VPS basic dispose de 500 Mo de RAM selon la liste des offres de DreamHost. Lors de notre test, MySQL avec ses paramètres par défaut s'est arrêté à une limite de 512 Mo sous charge, même avec une petite base de données. DreamHost configure lui-même MySQL sur chaque offre et ne publie pas les paramètres de VPS basic : demandez donc au support à quels usages cette offre convient avant d'y déplacer une base de données très sollicitée.

Avant de choisir, vérifiez la taille de vos bases de données. Le guide de DreamHost sur l'optimisation d'une base de données fournit la requête suivante. Connectez-vous à la base de données via SSH et exécutez-la pour afficher, en Mo, les données et les index de chaque base de données :

SELECT table_schema "database", sum(data_length + index_length)/1024/1024 "size in MB" FROM information_schema.TABLES GROUP BY table_schema;

Si le total dépasse largement la RAM de l'offre, MySQL ne peut pas tout garder en mémoire : commencez donc par la taille au-dessus.

Ce que 1 Go a pu contenir sur notre VM de test

Nous avons testé cette règle avant de nous y fier. Sur une VM de test, nous avons imposé à MySQL 8.4 une limite mémoire stricte égale à la RAM de chaque offre MySQL VPS, avec un cache d'environ la moitié de cette limite, puis nous avons appliqué une charge constante de type web à trois tailles de base de données. Le tableau indique la part des lectures auxquelles MySQL a répondu depuis la mémoire et la durée des 5 % de transactions les plus lentes. Chaque transaction est un lot de lectures et d'écritures, un peu comme l'affichage d'une page.

Une base de données inférieure à la moitié de la RAM de l'offre est restée rapide. Dès que les données ont dépassé la RAM, les transactions les plus lentes ont ralenti : 18,6 ms pour la base de 1,8 Go avec 1 Go, contre 8,7 ms avec l'offre supérieure. À 4,6 Go avec 1 Go, MySQL n'a pas du tout pu suivre la charge. Une limite de 512 Mo, proche des 500 Mo de VPS basic, était trop faible pour MySQL avec ses paramètres par défaut : il utilisait environ 470 Mo avant même la première requête, et chaque exécution s'est arrêtée à la limite.

Ce sont nos paramètres de test, pas ceux de DreamHost. DreamHost configure MySQL sur chaque offre et ne publie pas la taille de son cache, et vous ne pouvez pas modifier les paramètres serveur de MySQL sur un MySQL VPS. Considérez ce tableau comme une indication de la quantité de données que chaque taille de mémoire contient confortablement. Le test complet, avec toutes les tailles de cache essayées, se trouve dans notre guide sur la quantité de RAM nécessaire à MySQL.

Nous ne pouvons pas vous dire combien de visiteurs chaque offre peut gérer, car cela dépend davantage de vos requêtes que de votre taille. Si vos temps aux heures de pointe remontent à mesure que vos données augmentent, augmentez la RAM depuis le panel.

Comment nous avons testé la question de la mémoire

Les chiffres de mémoire ont été mesurés par DreamHost sur une VM de test (arm64), et non sur un serveur DreamHost. Une limite mémoire stricte a remplacé la RAM de chaque offre MySQL VPS. Nous avons effectué ce test le 19 octobre 2026 pour notre guide de dimensionnement de la RAM, et cette page le réutilise. La VM tournait sous Ubuntu 24.04 avec Colima sur un Mac, avec 2 vCPU et sans swap. MySQL 8.4.11 tournait à partir de l'image Docker officielle avec ses paramètres par défaut, à l'exception de la taille du cache. sysbench générait une charge mixte de lectures et d'écritures concentrée sur un noyau de lignes très sollicitées, avec 8 threads à un rythme constant de 360 transactions par seconde et une fenêtre de mesure de 3 minutes après une période de chauffe.

La page MySQL VPS indique MySQL 8.0, et l'article du centre d'aide de DreamHost Utiliser des mots réservés dans MySQL 8 précise que sur un VPS, vous pouvez contacter le support pour demander une mise à niveau vers MySQL 8.4. Nous avons testé la version 8.4 : un serveur encore en 8.0 peut donc se comporter un peu différemment.

Ce que nous n'avons pas testé : les paramètres MySQL VPS propres à DreamHost, MySQL partagé, les temps de Query Monitor sur un compte réel, le réseau entre un serveur web et un MySQL VPS, les tables WordPress ou WooCommerce, et la durée de la migration. Chaque configuration n'a été exécutée qu'une fois. Les étapes de diagnostic et les détails des produits proviennent du centre d'aide et des pages produits citées dans les sources.

FAQ sur les bases de données lentes