MySQL identifie un utilisateur par le nom d'utilisateur et l'hôte. Lorsque MySQL effectue l'authentification lors de la connexion, MySQL recherche d'abord un nom d'hôte qui correspond exactement. S'il ne trouve pas de correspondance exacte, il recherche un hôte contenant un caractère générique '%'.
Quand vous avez fait le GRANT ... TO [email protected] , MySQL a créé un nouvel utilisateur (sans mot de passe, car il n'y avait pas de IDENTIFIED BY donné dans la déclaration.
Ensuite, que s'est-il passé lorsque vous avez tenté de vous connecter en tant que myuser depuis l'hôte local, mysqld a essayé de trouver une entrée correspondant à 'myuser'@'localhost' dans la table mysql.user et il l'a trouvé. Et la session a obtenu les privilèges attribués à cet utilisateur.
(Pour être un peu plus précis, mysqld ne regarde pas vraiment le contenu de la table mysql.user, ce qu'il regarde vraiment la structure en mémoire, qui a été peuplée à partir de la table quand elle a été construite. Une reconstruction de la structure de mémoire est déclenchée par une instruction GRANT, REVOKE ou FLUSH PRIVILEGES.)
Que se passait-il AVANT d'ajouter ce nouvel utilisateur, mysqld cherchait une correspondance exacte sur l'utilisateur et le nom d'hôte, et n'en trouvait pas. Mais il a trouvé une entrée avec le caractère générique '%', donc il correspondait à cela, donc la session a obtenu tous les privilèges accordés à l'utilisateur 'myuser'@'%'.
Les deux utilisateurs 'u'@'%' et 'u'@'localhost' sont séparés et distincts les uns des autres. Les privilèges doivent être accordés à chaque utilisateur individuellement. Tous les privilèges accordés à 'u'@'%' s'applique UNIQUEMENT à cet utilisateur et NON à 'u'@'localhost' .
