De combien de RAM MySQL a-t-il besoin, et quelle taille de buffer pool choisir ?

Ce guide vous aide à dimensionner un MySQL VPS, l'option complémentaire pour un site déjà hébergé chez DreamHost. MySQL VPS existe en quatre tailles, avec 500 Mo, 1 Go, 2 Go ou 4 Go de RAM selon la liste des offres du panel DreamHost. Pour savoir quelle taille il faut à une base de données, nous avons fait tourner des bases de 460 Mo, 1,8 Go et 4,6 Go avec la mémoire de chaque offre sur une VM de test (pas un serveur DreamHost). Nous avons ensuite compté le nombre de lectures auxquelles MySQL a répondu depuis la mémoire. Une réponse acceptée sur Server Fault règle le cache de MySQL à environ 80 % de la mémoire du serveur. Nos résultats ci-dessous montrent où cela pose problème sur les petits serveurs. Si vous gérez plutôt votre propre serveur de base de données sur un VPS, ces mêmes chiffres vous indiquent comment régler le pool.

Toute la base de données n'a pas besoin de tenir en RAM. Matthew Boehm, qui répond au nom de Percona sur son forum, a indiqué à un utilisateur qu'une base de 4 To peut fonctionner avec 2 Go de RAM à environ 100 requêtes en lecture seule par seconde. Vous n'avez pas encore confirmé que c'est bien la base de données qui ralentit vos pages ? Vu de l'extérieur, un plugin lent ou l'absence de cache de page peuvent produire les mêmes symptômes. Commencez alors par notre guide pour savoir si votre base de données ralentit votre site.

Ce que MySQL conserve dans le buffer pool InnoDB

L'essentiel va à un seul cache. InnoDB, le moteur qui stocke vos tables, conserve les données de tables et d'index dans son buffer pool au fur et à mesure qu'il les lit. Si les données dont une requête a besoin s'y trouvent déjà, MySQL répond depuis la mémoire. Sinon, MySQL va les chercher sur le disque, et des données plus anciennes sont évincées pour faire de la place. Le manuel de MySQL prévient qu'un pool trop petit vide sans cesse des pages dont il a de nouveau besoin un instant plus tard.

Sa taille est un paramètre, innodb_buffer_pool_size. La valeur par défaut de MySQL est de 128 Mo sur n'importe quel serveur. Avec son réglage automatique pour une machine qui n'exécute que MySQL, MySQL garde 128 Mo en dessous de 1 Go de mémoire et prend la moitié de la mémoire entre 1 Go et 4 Go. DreamHost ne publie pas la taille du cache utilisée par chaque offre, et un MySQL VPS n'offre ni accès root ni accès SSH : vous ne pouvez donc pas modifier ce paramètre.

Le reste de la mémoire de MySQL ne diminue pas avec l'offre. Sur notre VM de test, MySQL 8.4 avec ses réglages d'origine utilisait environ 470 Mo avant toute requête, avec un cache de seulement 128 Mo. Le décompte de MySQL lui-même montrait où partait cette mémoire. En plus du cache, il y avait un tampon de journal de 64 Mo et environ 150 Mo pour le Performance Schema, l'outil de suivi d'activité intégré à MySQL. Sous charge, une fois le cache rempli, le processus serveur consommait environ 450 à 740 Mo de plus que le cache. Sur un serveur de 4 Go, c'est une petite part. Sur 1 Go, c'est la majeure partie de la mémoire.

Ce que nous avons mesuré avec la RAM de chaque offre

DreamHost a effectué ce test le 19 octobre 2026 sur une VM de test (arm64, 2 vCPU), avec une limite de mémoire stricte fixée à la RAM de chaque offre. Il ne s'agit pas d'un serveur DreamHost : lisez donc les résultats comme ce que la mémoire de chaque offre peut contenir.

Nous avons évalué chaque test selon son taux de succès, c'est-à-dire la part des lectures auxquelles MySQL a répondu depuis son cache. Une base de données tient lorsque 99 % ou plus de ses lectures proviennent de la mémoire et que MySQL ne plante pas. Entre 95 % et 99 %, c'est juste. En dessous de 95 %, c'est trop petit. Le seuil de 95 % est celui de Boehm : selon lui, à 95 % ou plus, vous avez assez de mémoire. Le seuil de 99 % est le nôtre, plus strict.

Pour la base de 1,8 Go, cela signifie qu'environ 35 lectures sur 1 000 sont allées sur le disque avec 1 Go, 17 avec 2 Go et 1 avec 4 Go.

La taille du buffer pool a autant compté que la RAM. Voici la base de 1,8 Go sur 2 Go de mémoire, pour chaque taille de pool testée :

Avec la valeur par défaut de 128 Mo de MySQL, les taux de succès sont restés autour de 92 à 96 % à chaque limite, de 1 Go à 4 Go. Un cache d'environ la moitié de la RAM n'a jamais planté. Avec environ les trois quarts, MySQL a planté sur 1 Go et 2 Go dès que la base dépassait la taille du cache, car la partie fixe qui s'y ajoute n'avait plus de place. Sur 4 Go, les trois quarts ont bien fonctionné. D'après nos tests uniques, sur un serveur que vous gérez vous-même, environ la moitié de la RAM est donc le point de départ sûr pour innodb_buffer_pool_size à 1 Go et 2 Go. Gardez les trois quarts pour les serveurs de 4 Go ou plus.

Une limite de 512 Mo était trop faible pour les réglages d'origine de MySQL 8.4. MySQL en utilisait environ 470 Mo avant toute requête, et chaque test s'est arrêté en atteignant la limite, même avec la base de 460 Mo. VPS basic dispose de 500 Mo selon la liste des offres du panel DreamHost, et la page MySQL VPS indique que le serveur est préconfiguré. Un serveur configuré pour consommer moins de mémoire pourrait faire mieux que notre configuration d'origine. DreamHost ne publie pas les réglages de VPS basic : demandez donc au support à quel usage il convient avant d'y placer une base de données très sollicitée.

Pourquoi la partie active compte plus que le total

Dans la même réponse, Boehm estime la partie active à environ 10 à 20 % du total et juge cela typique. Une boutique avec trois ans de commandes lit les commandes du mois et ses produits en ligne bien plus souvent qu'une facture de 2023. Notre charge de test fonctionnait de la même façon : elle revenait sans cesse à un noyau de lignes très sollicitées. C'est ainsi qu'une base de 4,6 Go a obtenu 97,7 % de ses lectures depuis un cache de 2 Go.

Un rapport qui totalise toutes les commandes depuis le lancement sollicite toutes ces lignes à la fois. Nous n'avons pas testé ce pire scénario : nous ne pouvons donc pas dire de combien le score baisserait. Si votre site s'appuie sur des recherches, des rapports ou des exports portant sur des données anciennes, considérez les lignes du tableau comme le meilleur des cas et choisissez l'offre au-dessus.

Vérifiez votre propre base de données avant de choisir

Pour les deux premières étapes, vous n'avez besoin que du panel et de phpMyAdmin, et elles fonctionnent avec votre offre actuelle.

1. Identifiez votre serveur MySQL

   Ouvrez la page MySQL Databases de votre panel et lisez le nom du serveur en haut. L'article du centre d'aide de DreamHost sur la consultation des journaux de base de données explique ces noms : un nom commençant par iad1 correspond au MySQL partagé, et sql suivi d'un nombre signifie que vous êtes déjà sur un serveur MySQL privé.

2. Mesurez la taille de vos bases de données

   Exécutez cette requête dans l'onglet SQL de phpMyAdmin ou via SSH. Elle provient de l'article du centre d'aide de DreamHost sur l'optimisation d'une base de données et affiche en Mo les données et les index de chaque base.

   sqlCopier

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

3. Associez le total à une ligne du tableau

   Additionnez toutes les bases de données de votre compte, car selon le centre d'aide de DreamHost, toutes sont déplacées vers un nouveau MySQL VPS. Repérez ce total dans le tableau ci-dessus. S'il se situe entre deux lignes, prenez l'offre de la ligne correspondant à la plus grande taille. Cela laisse de la marge pour la croissance des données. Nous n'avons pas mesuré de vraies bases WordPress ou WooCommerce : c'est donc votre propre total qu'il faut utiliser.

4. Vérifiez le taux de réussite du cache après la migration

   Un MySQL VPS n'exécute que vos bases de données : ses compteurs ne concernent donc que vos bases. Lisez Innodb_buffer_pool_read_requests et Innodb_buffer_pool_reads avec SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';, puis calculez 1 moins le rapport entre les lectures et les demandes de lecture. SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; indique, en octets, la taille du cache attribuée à votre offre, pour que vous puissiez la comparer au tableau. Sur notre VM de test, un utilisateur ayant des droits sur une seule base pouvait lire les deux. Sur le MySQL partagé, les compteurs couvrent toutes les bases du serveur : c'est pourquoi cette vérification n'a lieu qu'après la migration.

Quand passer à l'offre supérieure

Passez à l'offre supérieure lorsque le taux de succès descend sous 95 % et y reste à mesure que vos données grandissent. La page MySQL VPS indique que vous pouvez augmenter votre RAM depuis le panneau de contrôle MySQL VPS, et le centre d'aide de DreamHost précise que la partie non utilisée de l'ancienne offre est créditée sur la nouvelle.

Ne payez pas pour de la mémoire avant d'avoir examiné vos requêtes les plus lentes. Plus loin dans la même discussion Percona, le rapport d'optimisation d'un utilisateur affichait un taux de succès de 100 % à côté de millions de jointures sans index. La réponse de Boehm a été brève : No amount of ram will fix a bad query. Notre guide pour trouver les requêtes MySQL lentes explique comment les repérer avec Query Monitor et EXPLAIN. Pour optimiser un serveur MySQL que vous gérez vous-même, consultez notre article sur l'amélioration des performances de base de données sur un VPS.

Au-delà de 4 Go de données actives

Si la partie très sollicitée de vos données dépasse les 4 Go de VPS enterprise, DreamHost propose deux solutions plus grandes. Un serveur dédié dispose de 16 Go de RAM ou plus et exécute MySQL sur la même machine que votre site. Selon l'aperçu de MySQL du centre d'aide de DreamHost, cela convient aux logiciels qui échangent de grandes quantités de données entre l'application et MySQL. La page MySQL VPS précise que vous y avez accès aux fichiers de configuration de MySQL. Si vous préférez gérer votre propre serveur de base de données, un VPS va jusqu'à 32 Go de RAM avec Stack 32 ; vous y installez MySQL et réglez vous-même le buffer pool.

Si vous envisagez plutôt une base de données cloud, notre guide comparant les tarifs de RDS for MySQL à ceux d'un serveur MySQL privé détaille le prix des deux.

Notre méthode de mesure

DreamHost a effectué le test le 19 octobre 2026, sous Ubuntu 24.04.4 avec Colima sur un Mac à puce Apple : arm64, 2 vCPU et pas de swap. MySQL 8.4.11 tournait à partir de l'image Docker officielle avec ses réglages par défaut. Seules exceptions : la taille du cache testée et deux options que nous avons désactivées (la sauvegarde du cache entre les redémarrages et le journal binaire). Une limite de mémoire Docker de 512 Mo, 1 Go, 2 Go ou 4 Go représentait chaque offre. Chaque base de données était composée de tables sysbench d'un million de lignes chacune. sysbench 1.0.20 générait une charge mixte de lectures et d'écritures favorisant un noyau de lignes très sollicitées, avec 8 threads à un rythme constant de 360 transactions par seconde. Chaque test comprenait un préchauffage de 2 minutes (5 pour la base de 4,6 Go) et une fenêtre de mesure de 3 minutes. Chaque cache a été testé à 128 Mo, à environ la moitié et à environ les trois quarts de la mémoire.

Ce test a ses limites. Un MySQL VPS s'exécute dans son propre conteneur Linux sur le matériel de DreamHost. La taille du cache, la limite de connexions et le swap de chaque offre ne sont pas publiés par DreamHost : vous n'obtiendrez donc pas des chiffres identiques sur un MySQL VPS. Chaque réglage n'a été testé qu'une fois : nous ne pouvons donc pas montrer la variation d'un test à l'autre, et de petits écarts peuvent relever du bruit. Nous n'avons pas testé le pire scénario où chaque ligne est également sollicitée. Nous n'avons pas non plus mesuré la mémoire par connexion, dimensionné de vraies bases WordPress ou WooCommerce, ni testé MySQL 8.0.

FAQ sur la mémoire de MySQL