MySQL peut-il profiter efficacement de 64 Go de RAM?

Nous avons rencontré un problème où l'interrogation d'une table qui a environ 50 millions de lignes et a une taille d'index de 4 Go (taille de la table d'environ 6 Go) entraîne la permutation de la mémoire du serveur de base de données et ralentit considérablement. Je suis presque sûr que cela a à voir avec le dépassement de la taille de la table temporaire et son échange sur le disque.

Si j'ai mis à niveau mon serveur de base de données de 32 Go de RAM à 64 Go de RAM, je me demande si la base de données MySQL sera en mesure de tirer pleinement parti de cette mémoire supplémentaire et de ne pas échanger. J'ai parcouru quelques-unes des variables (par exemple KEY_BUFFER_SIZE, etc ...), et elles semblent prendre en charge la définition de valeurs supérieures à 64 Go. Cependant, la documentation MySQL indique que tmp_table_size atteint 4 Go maximum.

La mise à niveau de la mémoire en vaut-elle la peine? Est-ce que le problème de "requête sur une grande table" en bénéficierait ou ne serait-il pas utile en raison de la limite de 4 Go? Je sais qu'il existe potentiellement d'autres solutions telles que la restructuration de la table à partitionner de différentes manières, etc ... mais sans rien changer à la table, une mémoire supplémentaire serait-elle utile?

De plus, en général, y a-t-il d'autres variables liées à la mémoire dont MySQL ne pourrait pas tirer parti lors du passage de 32 à 64 Go de RAM?

Nous utilisons Linux 64 bits (Ubuntu) comme serveur de base de données.

Merci, Galen

Si vous utilisez InnoDB, la variable la plus importante à définir est innodb_buffer_pool_size. Je le définirais à environ 80% de la mémoire de votre système. Une fois que vos caches se sont réchauffés après une certaine utilisation, vos données les plus actives (ensemble de données de travail) seront en mémoire (innodb_buffer_pool_size) et vos opérations dessus devraient être très rapides. Avec 64 Go de mémoire, vous pouvez certainement en contenir beaucoup. La mémoire est toujours un bon achat pour les serveurs DB.

Oui - si vous utilisez InnoDB et que vous avez une charge de travail intensive en lecture, vous pouvez absolument profiter de grandes quantités de RAM [en supposant que votre ensemble de données sera compatible avec mem - votre serveur sera extrêmement rapide].

J'utilise MySQL avec le stockage InnoDB sur des serveurs de 8 à 16 Go avec un ensemble de travail adapté en mémoire.

Peut-être vaudrait-il la peine de consacrer un peu plus de temps et d'efforts à rechercher ce qui fait que le système permute avant de dépenser de l'argent en mémoire?

32 Go de mémoire laisse beaucoup de mémoire disponible même après le chargement de la table entière, de l'index et de la temp_table maximale dans la mémoire. Une recherche rapide a fait apparaître ces deux documents qui pourraient être pertinents:

• Comment MySQL utilise les tables temporaires internes
• Comment MySQL utilise la mémoire

Si vous pensez que cela est dû à une très grande table temporaire en cours de création, vous pouvez envisager des moyens d'améliorer la requête pour éviter les tables temporaires.

Vous pouvez publier sur Stackoverflow une publication contenant le schéma, la requête, le plan d'explication et quelques détails du problème.