Oracle 5.0 Reference Manual page 1176

GRANT ALL ON test.* TO ''@'localhost' ...
In this case, any user who connects from the local host with the correct password for the anonymous
user will be permitted access, with the privileges associated with the anonymous-user account.
For additional information about user name and host name values in account names, see
Section 6.2.3, "Specifying Account
To specify quoted values, quote database, table, column, and routine names as identifiers. Quote user
names and host names as identifiers or as strings. Quote passwords as strings. For string-quoting
and identifier-quoting guidelines, see
Names".
The "_" and "%" wildcards are permitted when specifying database names in
grant privileges at the global or database levels. This means, for example, that if you want to use a "_"
character as part of a database name, you should specify it as "\_" in the
the user from being able to access additional databases matching the wildcard pattern; for example,
GRANT ... ON `foo\_bar`.* TO
Warning
If you permit anonymous users to connect to the MySQL server, you should
also grant privileges to all local users as user_name@localhost. Otherwise,
the anonymous user account for
during MySQL installation) is used when named users try to log in to the MySQL
server from the local machine. For details, see
Stage 1: Connection
To determine whether the preceding warning applies to you, execute the following query, which lists
any anonymous users:
SELECT Host, User FROM mysql.user WHERE User='';
To avoid the problem just described, delete the local anonymous user account using this statement:
DROP USER ''@'localhost';
supports host names up to 60 characters long. Database, table, column, and routine names can
GRANT
be up to 64 characters. User names can be up to 16 characters.
Warning
The permissible length for user names cannot be changed by altering the
mysql.user
which may even make it impossible for users to log in to the MySQL server.
You should never alter any of the tables in the
whatsoever except by means of the procedure described in
"mysql_upgrade
The user specification may indicate how the user should authenticate when connecting to the server,
through inclusion of an
statement. See Section 13.7.1.1,
When the
IDENTIFIED BY
becomes the new password for the account, even if the account exists and already has a password.
With no
IDENTIFIED BY
If the
NO_AUTO_CREATE_USER
statement does not exist in the
clause or provide an empty password, the user has no password. This is very insecure.
BY
Account Management Statements
Names".
Section 9.1.1, "String
....
Verification".
table. Attempting to do so results in unpredictable behavior
— Check Tables for MySQL
clause. The syntax is the same as for the
IDENTIFIED BY
"CREATE USER
clause is present and you have global grant privileges, the password
clause, the account password remains unchanged.
[536] SQL mode is not enabled and the account named in a
table,
mysql.user
1156
Literals", and
in the
localhost mysql.user
Section 6.2.4, "Access Control,
mysql
Upgrade".
Syntax".
creates it. If you specify no
GRANT
Section 9.2, "Schema Object
statements that
GRANT
statement, to prevent
GRANT
table (created
database in any manner
Section 4.4.9,
CREATE USER
GRANT
IDENTIFIED