Peut-être une mesure de sécurité. Vous pouvez essayer d'ajouter un nouveau compte administrateur :
mysql> CREATE USER 'monty'@'localhost' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost'
-> WITH GRANT OPTION;
mysql> CREATE USER 'monty'@'%' IDENTIFIED BY 'some_pass';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
-> WITH GRANT OPTION;
Bien que Pascal et d'autres l'aient noté, ce n'est pas une bonne idée d'avoir un utilisateur avec ce type d'accès ouvert à n'importe quelle adresse IP. Si vous avez besoin d'un utilisateur administratif, utilisez root et laissez-le sur localhost. Pour toute autre action, spécifiez exactement les privilèges dont vous avez besoin et limitez l'accessibilité de l'utilisateur comme Pascal le suggère ci-dessous.
Modifier :
À partir de la FAQ MySQL :
Si vous ne pouvez pas comprendre pourquoi vous avez refusé getAccess, supprimez de la table utilisateur toutes les entrées dont les valeurs Host contiennent des caractères génériques (entrées contenant les caractères '%' ou '_'). Une erreur très courante consiste à insérer une nouvelle entrée avec Host='%' et User='some_user', pensant que cela vous permet de spécifier localhost pour vous connecter depuis la même machine. La raison pour laquelle cela ne fonctionne pas est que les privilèges par défaut incluent une entrée avec Host='localhost' et User=''. Étant donné que cette entrée a une valeur d'hôte 'localhost' plus spécifique que '%', elle est utilisée de préférence à la nouvelle entrée lors de la connexion à partir de localhost ! La procédure correcte consiste à insérer une deuxième entrée avec Host='localhost' et User='some_user', ou à supprimer l'entrée avec Host='localhost' et User=''. Après avoir supprimé l'entrée, n'oubliez pas d'émettre une instruction FLUSH PRIVILEGES pour recharger les tables d'octroi.
