MySQL identificerer en bruger ved BÅDE brugernavnet og værten. Når MySQL udfører godkendelsen ved login, leder MySQL først efter et værtsnavn, der er et nøjagtigt match. Hvis den ikke finder et nøjagtigt match, søger den efter en vært, der indeholder et '%' jokertegn.
Da du gjorde GRANT ... TO [email protected] , MySQL oprettede en ny bruger (uden adgangskode, fordi der ikke var nogen IDENTIFIED BY angivet i erklæringen.
Hvad skete der så, da du forsøgte at logge ind som myuser fra localhost, forsøgte mysqld at finde en post, der matchede 'myuser'@'localhost' i mysql.user-tabellen, og den fandt den. Og sessionen fik de privilegier, der blev tildelt den bruger.
(For at være lidt mere præcis ser mysqld ikke rigtig på indholdet af mysql.user-tabellen, hvad det egentlig ser ud på in-memory-strukturen, som blev udfyldt fra tabellen, da den blev bygget. En genopbygning af hukommelsesstrukturen udløses af en GRANT-, en REVOKE- eller en FLUSH PRIVILEGES-sætning.)
Hvad skete der FØR du tilføjede den nye bruger, ledte mysqld efter et nøjagtigt match på bruger og værtsnavn og fandt ikke et. Men den fandt en post med jokertegnet '%', så det matchede det, så sessionen fik alle de privilegier, der er givet til 'myuser'@'%'-brugeren.
De to brugere 'u'@'%' og 'u'@'localhost' er adskilte og adskilte fra hinanden. Privilegier skal gives til hver bruger individuelt. Eventuelle privilegier givet til 'u'@'%' gælder KUN for den bruger og IKKE for 'u'@'localhost' .