Problèmes connus dans les versions mineures de MySQL 8.0

Cette page décrit les problèmes connus et les incompatibilités 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 de version majeure, consultez la page Mettre à niveau la version majeure de la base de données sur place. Pour en savoir plus sur les journaux d'erreurs, consultez les pages et Afficher les journaux d'erreurs.

Problèmes de performances

Les sections suivantes couvrent les 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 pouvez 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 #99593.

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

  • Effectuez une mise à niveau vers 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, mettez à jour 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 pouvez 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 TempTable moteur.

Pour en savoir plus, consultez le bug MySQL #107700.

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

  • Effectuez une mise à niveau 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 une version ultérieure qui sont compatibles avec les applications clientes avec des threads à faible simultanéité peuvent rencontrer des problèmes de performances et des temps d'exécution des requêtes plus longs.

MySQL 8.0.22 a introduit l'option innodb_log_writer_threads pour améliorer les performances sur les systèmes à forte simultanéité. Cette option est activée par défaut. Si vous disposez d'instances créées dans MySQL 8.0.22 ou une 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 #93734.

Problèmes liés aux JOINS

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

Pour en savoir plus, consultez le bug MySQL #109361.

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

Problèmes liés aux clauses 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 la section Modifications dans MySQL 8.0.33.

Pour résoudre ce problème, effectuez une mise à niveau vers 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 couvrent les problèmes de fuite de mémoire connus dans MySQL 8.0 ou une version ultérieure. Ces problèmes ont également un impact probable sur les performances de l'instance.

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

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

Pour en savoir plus, consultez le bug MySQL #105331.

Pour résoudre ce problème, effectuez une mise à niveau vers 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 quantité de mémoire très élevée sous le fichier de code et la fonction memory/sql/sp_head::execute_mem_root.

Pour en savoir plus, consultez le bug MySQL #107327.

Pour résoudre ce problème, effectuez une mise à niveau vers 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 pouvez 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 pouvez rencontrer une fuite de mémoire. En effet, le rôle cloudsqlsuperuser dispose de droits de révocation partielle.

Pour en savoir plus, consultez le bug MySQL #103133.

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

  • Effectuez une mise à niveau 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 d'administration et non les requêtes d'application. Si la fuite de mémoire persiste, vous devez effectuer une mise à niveau vers MySQL 8.0.36, une version mineure ultérieure ou la dernière version.

Problèmes de réplication

La section suivante couvre les 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 répliquée multithread dont le composant slave_preserve_commit_order est activé et que l'instance est utilisée pour des charges de travail à forte écriture, les opérations d'instance peuvent s'interrompre indéfiniment en raison d'un interblocage et d'un temps de latence de réplication qui s'accumule.

Ce problème est observé dans MySQL 8.0.27 à MySQL 8.0.32.

Pour en savoir plus, consultez le bug MySQL #95863 et le bug MySQL #103636.

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

  • Effectuez une mise à niveau vers MySQL 8.0.33, une version mineure ultérieure ou la dernière version.
  • Désactivez la réplication parallèle pour vérifier 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

Les sections suivantes abordent les problèmes connus liés aux droits.

Modifications apportées aux droits

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, les utilisateurs créés dans MySQL 5.7 peuvent ne pas disposer des mêmes droits et du même 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 d'accès refusé dans les scénarios suivants :

  • Les utilisateurs mis à niveau à partir de 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 mis à niveau à partir de MySQL 5.7 peuvent ne pas être en mesure d'exécuter la KILL commande, qui nécessite désormais des CONNECTION_ADMIN droits pour fonctionner dans MySQL 8.0.

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

Un exemple de message d'erreur se présente comme suit :

    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 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 pour terminer la mise à niveau de 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 entraînent une erreur d'accès refusé

Les utilisateurs créés dans MySQL 5.7 et mis à niveau vers MySQL 8.0 peuvent ne pas être en mesure de se connecter à la base de données en raison d'un problème de droits. 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'utilisateur.

Si les utilisateurs créés dans MySQL 5.7 ont été définis à l'aide de caractères génériques, ils peuvent ne pas être en mesure de se connecter à la base de données. Les caractères génériques ne sont plus compatibles avec MySQL 8.0.16 ni les versions ultérieures. Cela signifie que MySQL ne peut pas trouver de correspondance exacte pour la base de données et l'utilisateur, ce qui peut entraîner l'omission de certaines attributions de droits existantes lors de la mise à niveau.

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

Pour en savoir plus, consultez les pages 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 apportées aux valeurs des options entre MySQL 5.7 et MySQL 8.0

Lorsque vous effectuez une mise à niveau de MySQL 5.7 vers 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 la section Nouvelles valeurs par défaut dans MySQL 8.0.

Pour résoudre ce problème, assurez-vous que toutes les valeurs d'options 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 laisser les valeurs par défaut attribuées aux options système.

Étape suivante