MySQL identifierar en användare med BÅDE användarnamnet och värden. När MySQL gör autentiseringen vid inloggning, letar MySQL först efter ett värdnamn som är en exakt matchning. Om den inte hittar en exakt matchning letar den efter en värd som innehåller ett "%" jokertecken.
När du gjorde GRANT ... TO [email protected] , MySQL skapade en ny användare (utan lösenord, eftersom det inte fanns någon IDENTIFIED BY anges i uttalandet.
Vad hände sedan när du försökte logga in som myuser från localhost försökte mysqld hitta en post som matchade 'myuser'@'localhost' i tabellen mysql.user och den hittade den. Och sessionen fick de privilegier som tilldelats den användaren.
(För att vara lite mer exakt, mysqld tittar inte riktigt på innehållet i mysql.user-tabellen, hur det egentligen ser ut på in-memory-strukturen, som fylldes i från tabellen när den byggdes. En ombyggnad av minnesstrukturen utlöses av en GRANT-, en REVOKE- eller en FLUSH PRIVILEGES-sats.)
Vad som hände INNAN du lade till den nya användaren, letade mysqld efter en exakt matchning av användaren och värdnamnet och hittade ingen. Men den hittade en post med jokertecknet '%', så det matchade det, så sessionen fick alla privilegier som beviljats 'myuser'@'%'-användaren.
De två användarna 'u'@'%' och 'u'@'localhost' är separata och skilda från varandra. Behörigheter måste ges till varje användare individuellt. Eventuella privilegier som ges till 'u'@'%' gäller ENDAST för den användaren och INTE för 'u'@'localhost' .