Problèmes connus dans les versions mineures de MySQL 8.0

Cette page décrit les problèmes et les incompatibilités connus que vous pouvez rencontrer après avoir effectué une mise à niveau de version majeure de Cloud SQL pour MySQL 5.7 vers Cloud SQL pour MySQL 8.0.

Pour en savoir plus sur la mise à niveau d'une version majeure, consultez Mettre à niveau la version majeure de la base de données sur place. Pour en savoir plus sur les journaux d'erreurs, consultez Afficher les journaux d'erreurs.

Problèmes de performances

Les sections suivantes traitent des problèmes de performances connus.

Problèmes liés à la requête SELECT DISTINCT

Si vous utilisez la requête SELECT DISTINCT dans MySQL 8.0.18 à MySQL 8.0.20, vous risquez de constater une baisse des performances. Les temps d'exécution des requêtes peuvent être trois fois plus longs que dans MySQL 5.7.

Pour en savoir plus, consultez le bug MySQL n° 99593.

Pour résoudre ce problème, suivez les recommandations de dépannage ci-dessous :

  • Passez à MySQL 8.0.21, à une version mineure ultérieure ou à la dernière version.
  • Si vous utilisez MySQL 8.0.18 à MySQL 8.0.20, définissez la valeur de l'option de base de données internal_tmp_mem_storage_engine sur memory : 
        SET SESSION internal_tmp_mem_storage_engine='memory' ;

Problèmes liés aux requêtes GROUP BY

Si vous utilisez des requêtes SELECT... GROUP BY dans MySQL 8.0.36 ou une version antérieure, vous risquez de constater une baisse des performances et une augmentation des temps d'exécution des requêtes.

Cela peut se produire si la requête utilise le moteur TempTable.

Pour en savoir plus, consultez le bug MySQL n° 107700.

Pour résoudre ce problème, suivez les recommandations de dépannage ci-dessous :

  • Mettez à jour vers MySQL 8.0.37, une version mineure ultérieure ou la dernière version.
  • Si vous utilisez MySQL 8.0.36 ou une version antérieure, mettez à jour l'indicateur de base de données internal_tmp_mem_storage_engine pour utiliser le moteur de mémoire plutôt que le moteur de table temporaire : 
        SET SESSION internal_tmp_mem_storage_engine='memory' ;

Problèmes liés aux threads à faible simultanéité

Les instances créées dans MySQL 8.0.22 ou version ultérieure qui acceptent les applications clientes avec des threads à faible simultanéité peuvent rencontrer des problèmes de performances et des temps d'exécution de requêtes plus longs.

MySQL 8.0.22 a introduit l'indicateur innodb_log_writer_threads pour améliorer les performances sur les systèmes à forte concurrence. Cette option est activée par défaut. Si vous avez créé des instances dans MySQL 8.0.22 ou version ultérieure qui sont compatibles avec les applications clientes avec des threads à faible simultanéité, nous vous recommandons de désactiver l'option innodb_log_writer_threads.

Pour en savoir plus, consultez le bug MySQL n° 93734.

Problèmes liés à JOINS

Si vous utilisez des requêtes JOIN avec la vue eq_ref dans des instances utilisant MySQL 8.0.29 à MySQL 8.0.32, vous risquez de rencontrer des problèmes de performances importants.

Pour en savoir plus, consultez le bug MySQL n° 109361.

Pour résoudre ce problème, passez à MySQL 8.0.33, à une version mineure ultérieure ou à la dernière version.

Problèmes liés à la clause LIMIT et ORDER BY

Si vous exécutez une requête avec les clauses LIMIT et ORDER BY dans MySQL 8.0.32 ou une version antérieure, vous pouvez rencontrer un problème de performances. Dans certains cas, un plan de requête différent peut être utilisé dans MySQL 8.0 par rapport à MySQL 5.7 pour la même requête.

Pour en savoir plus, consultez Modifications apportées à MySQL 8.0.33.

Pour résoudre ce problème, passez à MySQL 8.0.33, à une version mineure ultérieure ou à la dernière version.

Problèmes de fuite de mémoire dans MySQL 8.0

Les sections suivantes traitent des problèmes de fuite de mémoire connus dans MySQL 8.0 ou version ultérieure. Ces problèmes ont probablement aussi un impact sur les performances de l'instance.

Fuite de mémoire causée par les requêtes de plage

Si vous utilisez l'optimiseur de plage dans des instances avec MySQL 8.0.16 à MySQL 8.0.28, une forte consommation de mémoire peut se produire par le fichier de code et la fonction memory/sql/THD::main_mem_root. Cela peut entraîner une saturation de la mémoire de l'instance.

Pour en savoir plus, consultez le bug MySQL n° 105331.

Pour résoudre ce problème, passez à MySQL 8.0.29, à une version mineure ultérieure ou à la dernière version.

Fuite de mémoire associée aux procédures stockées

Si vous exécutez une requête dans une procédure stockée dans des instances avec MySQL 8.0.27 à 8.0.31, la requête peut consommer une très grande quantité de mémoire sous le fichier et la fonction de code memory/sql/sp_head::execute_mem_root.

Pour en savoir plus, consultez le bug MySQL n° 107327.

Pour résoudre ce problème, passez à MySQL 8.0.32, à une version mineure ultérieure ou à la dernière version.

Fuite de mémoire causée par l'accès à une vue à l'aide de SELECT

Si vous utilisez la requête SELECT dans MySQL 8.0.35 ou une version antérieure, et que votre application utilise de nombreux appels de vue, vous risquez de constater une fuite de mémoire notable.

De plus, si la vue DEFINER est définie sur root@'%' ou sur un utilisateur dérivé du rôle cloudsqlsuperuser, vous risquez de rencontrer une fuite de mémoire. En effet, le rôle cloudsqlsuperuser dispose de droits de révocation partiels.

Pour en savoir plus, consultez le bug MySQL n° 103133.

Pour résoudre ce problème, suivez les recommandations de dépannage ci-dessous :

  • Mettez à jour vers MySQL 8.0.36, une version mineure ultérieure ou la dernière version.
  • Si vous utilisez MySQL 8.0.35 ou une version antérieure, utilisez un utilisateur distinct pour la vue DEFINER, en particulier un utilisateur qui ne dispose pas de droits de révocation partielle. Si vous devez utiliser l'utilisateur root@'%' ou le rôle cloudsqlsuperuser, assurez-vous de ne les utiliser que pour les processus administratifs et non pour les requêtes d'application. Si la fuite de mémoire persiste, vous devez passer à MySQL 8.0.36, à une version mineure ultérieure ou à la dernière version.

Problèmes de réplication

La section suivante traite des problèmes connus liés à la réplication.

Problèmes liés à la réplication parallèle

Si vous utilisez la réplication parallèle dans une instance dupliquée multithread dont le composant slave_preserve_commit_order est activé et que l'instance est utilisée pour des charges de travail à fort volume d'écriture, les opérations d'instance peuvent être mises en pause indéfiniment en raison d'un blocage et d'un délai de réplication qui s'accumule.

Ce problème se produit dans MySQL 8.0.27 à MySQL 8.0.32.

Pour en savoir plus, consultez les bugs MySQL n° 95863 et 103636.

Pour résoudre ce problème, suivez les recommandations de dépannage ci-dessous :

  • Mettez à jour vers MySQL 8.0.33, une version mineure ultérieure ou la dernière version.
  • Désactivez la réplication parallèle pour identifier la cause de ce problème, puis planifiez une mise à niveau appropriée. Bien que la désactivation de la réplication parallèle puisse résoudre temporairement le problème, elle n'est pas recommandée comme solution à long terme.

Problèmes de droits d'accès

Les sections suivantes décrivent les problèmes connus liés aux droits d'accès.

Modifications apportées aux droits d'accès

MySQL a modifié les systèmes de sécurité et de gestion des comptes dans MySQL 8.0.

Après la mise à niveau vers MySQL 8.0, il est possible que les utilisateurs créés dans MySQL 5.7 ne disposent pas des mêmes droits et accès que ceux créés dans MySQL 8.0. Par conséquent, les utilisateurs créés dans MySQL 5.7 peuvent recevoir un message d'erreur "Accès refusé" dans les scénarios suivants :

  • Les utilisateurs migrés depuis MySQL 5.7 peuvent ne pas disposer des droits CREATE ROLE et DROP ROLE, car ces droits n'existaient pas dans MySQL 5.7.
  • Les utilisateurs migrés depuis MySQL 5.7 peuvent ne pas être en mesure d'exécuter la commande KILL, qui nécessite désormais des droits CONNECTION_ADMIN pour fonctionner dans MySQL 8.0.

Pour en savoir plus, vous pouvez consulter tous les droits disponibles dans MySQL 8.0.

Voici un exemple de message d'erreur :

    ERROR 1227 (42000): Access denied; you need (at least one of) the GRANT OPTION privilege(s) for this operation

Vous ne pouvez pas attribuer directement ces droits d'accès mis à jour à un utilisateur existant. Pour résoudre ce problème, un administrateur disposant des droits GRANT OPTION doit réinitialiser les droits d'utilisateur après la mise à niveau afin de terminer la mise à niveau de la version majeure.

Pour en savoir plus, consultez la page Mettre à niveau la version majeure de la base de données sur place.

Les modifications apportées aux droits d'accès entraînent une erreur "Accès refusé"

Les utilisateurs créés dans MySQL 5.7 et migrés vers MySQL 8.0 peuvent ne pas pouvoir se connecter à la base de données en raison d'un problème de droits d'accès. Dans ce cas, les utilisateurs peuvent recevoir le message d'erreur suivant :

    Access denied for user 'USER_NAME'@'%' to database 'MY_DATABASE_NAME' ;

MySQL 8.0.16 a introduit l'option de base de données partial_revokes et l'a activée par défaut, ce qui permet de révoquer partiellement les droits d'accès des utilisateurs.

Si des utilisateurs créés dans MySQL 5.7 ont été définis à l'aide de caractères génériques, il est possible qu'ils ne puissent pas se connecter à la base de données. Les caractères génériques ne sont plus acceptés dans MySQL 8.0.16 ni les versions ultérieures. Cela signifie que MySQL ne trouve pas de correspondance exacte pour la base de données et l'utilisateur, ce qui peut entraîner l'oubli de certaines attributions de droits d'accès existantes lors de la mise à niveau.

Ce problème affecte MySQL 8.0.16 ou version ultérieure.

Pour en savoir plus, consultez Configurer des options de base de données et Sécurité et gestion des comptes.

Pour résoudre ce problème, un administrateur doit attribuer manuellement des autorisations aux utilisateurs dans MySQL 8.0.

Modifications des valeurs des options entre MySQL 5.7 et MySQL 8.0

Lorsque vous passez de MySQL 5.7 à MySQL 8.0, certaines valeurs d'options de base de données peuvent être modifiées en raison d'un changement de valeurs par défaut entre les versions. Ce comportement peut entraîner des problèmes de performances.

Pour en savoir plus, consultez Nouvelles valeurs par défaut dans MySQL 8.0.

Pour résoudre ce problème, assurez-vous que toutes les valeurs d'indicateurs de base de données attribuées manuellement dans MySQL 5.7 sont toujours appliquées après la mise à niveau vers MySQL 8.0 ou une version ultérieure. Nous vous recommandons de conserver les valeurs par défaut attribuées aux options système.

Étapes suivantes