MySQL Account Management Statements
13.7.1.1.
CREATE USER Statement
Syntax:
CREATE USER user_specification
[, user_specification] ...
user_specification:
user [IDENTIFIED BY [PASSWORD] 'password']
The CREATE USER statement creates new MySQL accounts. To use it, you must have the global CREATE
USER privilege or the INSERT privilege for the mysql database. For each account, CREATE USER creates a
new row in the mysql.user table and assigns the account no privileges. An error occurs if the account already
exists.
Each account name uses the format described in Section 6.2.3, “Specifying Account Names”. For example:
CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
If you specify only the user name part of the account name, a host name part of '%' is used.
The user specification may indicate how the user should authenticate when connecting to the server:







To enable the user to connect with no password (which is insecure), include no IDENTIFIED BY clause:
CREATE USER 'jeffrey'@'localhost';
To assign a password, use IDENTIFIED BY with the literal plaintext password value:
CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
To avoid specifying the plaintext password if you know its hash value (the value that PASSWORD()
would return for the password), specify the hash value preceded by the keyword PASSWORD:
CREATE USER 'jeffrey'@'localhost'
IDENTIFIED BY PASSWORD '*90E462C37378CED12064BB3388827D2BA3A9B689';
For additional information about setting passwords, see Section 6.3.5, “Assigning Account Passwords”.
Important: CREATE USER may be recorded in server logs or in a history file such as ~/.mysql_history, which
means that cleartext passwords may be read by anyone having read access to that information. See
Section 6.1.2, “Keeping Passwords Secure”.
Important: Some releases of MySQL introduce changes to the structure of the grant tables to add new
privileges or features. Whenever you update to a new version of MySQL, you should update your grant
tables to make sure that they have the current structure so that you can take advantage of any new
capabilities. See Section 4.4.9, “mysql_upgrade — Check Tables for MySQL Upgrade”.
The CREATE USER statement was added in MySQL 5.0.2.
13.7.1.2.
Syntax:
DROP USER Statement
DROP USER user [, user] ...
The DROP USER statement removes one or more MySQL accounts. To use it, you must have the global
CREATE USER privilege or the DELETE privilege for the mysql database. Each account name uses the format
described in Section 6.2.3, “Specifying Account Names”. For example:
DROP USER 'jeffrey'@'localhost';
If you specify only the user name part of the account name, a host name part of '%' is used.
DROP USER as present in MySQL 5.0.0 removes only accounts that have no privileges. In MySQL 5.0.2, it
was modified to remove account privileges as well. This means that the procedure for removing an account
depends on your version of MySQL.
As of MySQL 5.0.2, you can remove an account and its privileges as follows:
DROP USER user;
The statement removes privilege rows for the account from all grant tables.
Before MySQL 5.0.2, DROP USER serves only to remove account rows from the user table for accounts that
have no privileges. To remove a MySQL account completely (including all of its privileges), you should use
the following procedure, performing these steps in the order shown:
1. Use SHOW GRANTS to determine what privileges the account has. See Section 13.7.5.17, “SHOW
GRANTS Syntax”.
2. Use REVOKE to revoke the privileges displayed by SHOW GRANTS. This removes rows for the
account from all the grant tables except the user table, and revokes any global privileges listed in
the user table. See Section 13.7.1.3, “GRANT Syntax”.
3. Delete the account by using DROP USER to remove the user table row.
Important: DROP USER does not automatically close any open user sessions. Rather, in the event that a user
with an open session is dropped, the statement does not take effect until that user's session is closed. Once
the session is closed, the user is dropped, and that user's next attempt to log in will fail. This is by design.
DROP USER does not automatically drop or invalidate databases or objects within them that the old user
created. This includes stored programs or views for which the DEFINER attribute names the dropped user.
Attempts to access such objects may produce an error if they execute in definer security context. (For
information about security context, see Section 18.5, “Access Control for Stored Programs and Views”.)
13.7.1.3. GRANT Statement
 The GRANT statement grants privileges to MySQL user accounts. It also serves to specify other
account characteristics such as use of secure connections and limits on access to server resources.
Syntax:
GRANT
priv_type [(column_list)]
[, priv_type [(column_list)]] ...
ON [object_type] priv_level
TO user_specification [, user_specification] ...
[REQUIRE {NONE | ssl_option [[AND] ssl_option] ...}]
[WITH with_option ...]
object_type:
TABLE
| FUNCTION
| PROCEDURE
priv_level:
*
| *.*
| db_name.*
| db_name.tbl_name
| tbl_name
| db_name.routine_name
user_specification:
user [IDENTIFIED BY [PASSWORD] 'password']
ssl_option:
SSL
| X509
| CIPHER 'cipher'
| ISSUER 'issuer'
| SUBJECT 'subject'
with_option:
GRANT OPTION
| MAX_QUERIES_PER_HOUR count
| MAX_UPDATES_PER_HOUR count
| MAX_CONNECTIONS_PER_HOUR count
| MAX_USER_CONNECTIONS count
Notations:


To use GRANT, you must have the GRANT OPTION privilege, and you must have the privileges that you are granting.
Normally, a database administrator first uses CREATE USER to create an account, then GRANT to define its
privileges and characteristics.
Examples:
CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
GRANT ALL ON db1.* TO 'jeffrey'@'localhost';
GRANT SELECT ON db2.invoice TO 'jeffrey'@'localhost';
GRANT USAGE ON *.* TO 'jeffrey'@'localhost' WITH MAX_QUERIES_PER_HOUR 90;
However, if an account named in a GRANT statement does not already exist, GRANT may create it under the conditions
described later in the discussion of the NO_AUTO_CREATE_USER SQL mode.
The REVOKE statement is related to GRANT and enables administrators to remove account privileges. See Section 13.7.1.5,
“REVOKE Syntax”.
When successfully executed from the mysql program, GRANT responds with Query OK, 0 rows affected. To determine what
privileges result from the operation, use SHOW GRANTS. See Section 13.7.5.17, “SHOW GRANTS Syntax”.
There are several aspects to the GRANT statement, described under the following topics in this section:









Privileges Supported by MySQL
Global Privileges
Database Privileges
Table Privileges
Column Privileges
Stored Routine Privileges
Account Names and Passwords
Other Account Characteristics
MySQL and Standard SQL Versions of GRANT
Important: Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or
features. Whenever you update to a new version of MySQL, you should update your grant tables to make sure that they
have the current structure so that you can take advantage of any new capabilities. See Section 4.4.9, “mysql_upgrade —
Check Tables for MySQL Upgrade”.
Privileges Supported by MySQL
The following table summarizes the permissible priv_type privilege types that can be specified for the GRANT and REVOKE
statements. For additional information about these privileges, see Section 6.2.1, “Privileges Provided by MySQL”.
Table 13.1. Permissible Privileges for GRANT and REVOKE
Privilege
Meaning
ALL [PRIVILEGES]
Grant all privileges at specified access level except GRANT OPTION
ALTER
Enable use of ALTER TABLE
ALTER ROUTINE
Enable stored routines to be altered or dropped
CREATE
Enable database and table creation
CREATE ROUTINE
Enable stored routine creation
CREATE
TABLES
Enable use of CREATE TEMPORARY TABLE
TEMPORARY
CREATE USER
Enable use of CREATE USER, DROP USER, RENAME USER, and REVOKE ALL PRIVILEGES
CREATE VIEW
Enable views to be created or altered
DELETE
Enable use of DELETE
DROP
Enable databases, tables, and views to be dropped
EXECUTE
Enable the user to execute stored routines
FILE
Enable the user to cause the server to read or write files
GRANT OPTION
Enable privileges to be granted to or removed from other accounts
INDEX
Enable indexes to be created or dropped
INSERT
Enable use of INSERT
LOCK TABLES
Enable use of LOCK TABLES on tables for which you have the SELECT privilege
PROCESS
Enable the user to see all processes with SHOW PROCESSLIST
REFERENCES
Not implemented
RELOAD
Enable use of FLUSH operations
REPLICATION CLIENT
Enable the user to ask where master or slave servers are
REPLICATION SLAVE
Enable replication slaves to read binary log events from the master
SELECT
Enable use of SELECT
SHOW DATABASES
Enable SHOW DATABASES to show all databases
SHOW VIEW
Enable use of SHOW CREATE VIEW
SHUTDOWN
Enable use of mysqladmin shutdown
SUPER
Enable use of other administrative operations such as CHANGE MASTER TO, KILL, PURGE BINARY
LOGS, SET GLOBAL, and mysqladmin debug command
UPDATE
Enable use of UPDATE
USAGE
Synonym for “no privileges”
The EXECUTE privilege is not operational until MySQL 5.0.3. CREATE VIEW and SHOW VIEW were added in MySQL 5.0.1.
CREATE USER, CREATE ROUTINE, and ALTER ROUTINE were added in MySQL 5.0.3.
In GRANT statements, the ALL [PRIVILEGES] privilege is named by itself and cannot be specified along with other privileges.
It stands for all privileges available for the level at which privileges are to be granted except for the GRANT OPTION
privilege.
USAGE can be specified to create a user that has no privileges, or to specify the REQUIRE or WITH clauses for an account
without changing its existing privileges.
MySQL account information is stored in the tables of the mysql database. This database and the access control system are
discussed extensively in Section 6.2, “The MySQL Access Privilege System”, which you should consult for additional details.
If the grant tables hold privilege rows that contain mixed-case database or table names and the lower_case_table_names
system variable is set to a nonzero value, REVOKE cannot be used to revoke these privileges. It will be necessary to
manipulate the grant tables directly. (GRANT will not create such rows when lower_case_table_names is set, but such rows
might have been created prior to setting that variable.)
Privileges can be granted at several levels, depending on the syntax used for the ON clause. For REVOKE, the same ON
syntax specifies which privileges to take away. The examples shown here include no IDENTIFIED BY 'password' clause for
brevity, but you should include one if the account does not already exist, to avoid creating an insecure account that has no
password.
Global Privileges
Global privileges are administrative or apply to all databases on a given server. To assign global privileges, use ON *.*
syntax:
GRANT ALL ON *.* TO 'someuser'@'somehost';
GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';
Before MySQL 5.0.23, privileges also are assigned at the global level if you use ON * syntax and you have not selected a
default database. As of 5.0.23, ON * requires a default database and produces an error if there is none.
The CREATE USER, FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN,
and SUPER privileges are administrative and can only be granted globally.
Other privileges can be granted globally or at more specific levels.
MySQL stores global privileges in the mysql.user table.
Database Privileges
Database privileges apply to all objects in a given database. To assign database-level privileges, use ON db_name.* syntax:
GRANT ALL ON mydb.* TO 'someuser'@'somehost';
GRANT SELECT, INSERT ON mydb.* TO 'someuser'@'somehost';
If you use ON * syntax (rather than ON *.*) and you have selected a default database, privileges are assigned at the
database level for the default database. An error occurs if there is no default database.
The CREATE, DROP, GRANT OPTION, and LOCK TABLES privileges can be specified at the database level. Table or routine
privileges also can be specified at the database level, in which case they apply to all tables or routines in the database.
MySQL stores database privileges in the mysql.db table.
Table Privileges
Table privileges apply to all columns in a given table. To assign table-level privileges, use ON db_name.tbl_name syntax:
GRANT ALL ON mydb.mytbl TO 'someuser'@'somehost';
GRANT SELECT, INSERT ON mydb.mytbl TO 'someuser'@'somehost';
If you specify tbl_name rather than db_name.tbl_name, the statement applies to tbl_name in the default database. An error
occurs if there is no default database.
The permissible priv_type values at the table level are ALTER, CREATE VIEW, CREATE, DELETE, DROP, GRANT OPTION,
INDEX, INSERT, SELECT, SHOW VIEW, and UPDATE.
MySQL stores table privileges in the mysql.tables_priv table.
Column Privileges
Column privileges apply to single columns in a given table. Each privilege to be granted at the column level must be followed
by the column or columns, enclosed within parentheses.
GRANT SELECT (col1), INSERT (col1,col2) ON mydb.mytbl TO 'someuser'@'somehost';
The permissible priv_type values for a column (that is, when you use a column_list clause) are INSERT, SELECT, and UPDATE.
MySQL stores column privileges in the mysql.columns_priv table.
Stored Routine Privileges
The ALTER ROUTINE, CREATE ROUTINE, EXECUTE, and GRANT OPTION privileges apply to stored routines (procedures and
functions). They can be granted at the global and database levels. Except for CREATE ROUTINE, these privileges can be
granted at the routine level for individual routines.
GRANT CREATE ROUTINE ON mydb.* TO 'someuser'@'somehost';
GRANT EXECUTE ON PROCEDURE mydb.myproc TO 'someuser'@'somehost';
The permissible priv_type values at the routine level are ALTER ROUTINE, EXECUTE, and GRANT OPTION. CREATE ROUTINE
is not a routine-level privilege because you must have this privilege to create a routine in the first place.
MySQL stores routine-level privileges in the mysql.procs_priv table.
For the global, database, table, and routine levels, GRANT ALL assigns only the privileges that exist at the level you are
granting. For example, GRANT ALL ON db_name.* is a database-level statement, so it does not grant any global-only
privileges such as FILE.
The object_type clause was added in MySQL 5.0.6. If present, it should be specified as TABLE, FUNCTION, or PROCEDURE
when the following object is a table, a stored function, or a stored procedure.
The privileges for a database, table, column, or routine are formed additively as the logical OR of the privileges at each
of the privilege levels. For example, if a user has a global SELECT privilege, the privilege cannot be denied by an absence
of the privilege at the database, table, or column level. Details of the privilege-checking procedure are presented in
Section 6.2.5, “Access Control, Stage 2: Request Verification”.
MySQL enables you to grant privileges on databases or tables that do not exist. For tables, the privileges to be granted
must include the CREATE privilege. This behavior is by design, and is intended to enable the database administrator to
prepare user accounts and privileges for databases or tables that are to be created at a later time.
Important: MySQL does not automatically revoke any privileges when you drop a database or table. However, if you drop
a routine, any routine-level privileges granted for that routine are revoked.
Account Names and Passwords
The user value indicates the MySQL account to which the GRANT statement applies. To accommodate granting rights to users
from arbitrary hosts, MySQL supports specifying the user value in the form user_name@host_name. If a user_name or host_name
value is legal as an unquoted identifier, you need not quote it. However, quotation marks are necessary to specify a
user_name string containing special characters (such as “-”), or a host_name string containing special characters or wildcard
characters (such as “%”); for example, 'test-user'@'%.com'. Quote the user name and host name separately.
You can specify wildcards in the host name. For example, user_name@'%.example.com' applies to user_name for any host
in the example.com domain, and user_name@'192.168.1.%' applies to user_name for any host in the 192.168.1 class C
subnet.
The simple form user_name is a synonym for user_name@'%'.
MySQL does not support wildcards in user names. To refer to an anonymous user, specify an account with an empty user name
with the GRANT statement:
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
Names”.
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
Section 9.1.1, “String Literals”, and Section 9.2, “Schema Object Names”.
The “_” and “%” wildcards are permitted when specifying database names in GRANT statements that 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 GRANT statement, to prevent 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 localhost in the mysql.user table (created during MySQL
installation) is used when named users try to log in to the MySQL server from the local machine. For details, see Section 6.2.4,
“Access Control, Stage 1: Connection Verification”.
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';
GRANT supports host names up to 60 characters long. Database, table, column, and routine names can 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 table. Attempting to do so results
in unpredictable behavior 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 mysql database in any manner whatsoever except by means of the procedure described in
Section 4.4.9, “mysql_upgrade — Check Tables for MySQL Upgrade”.
The user specification may indicate how the user should authenticate when connecting to the server, through inclusion of an
IDENTIFIED BY clause. The syntax is the same as for the CREATE USER statement. See Section 13.7.1.1, “CREATE USER
Syntax”.
When the IDENTIFIED BY clause is present and you have global grant privileges, the password becomes the new password
for the account, even if the account exists and already has a password. With no IDENTIFIED BY clause, the account password
remains unchanged.
If the NO_AUTO_CREATE_USER SQL mode is not enabled and the account named in a GRANT statement does not exist in
the mysql.user table, GRANT creates it. If you specify no IDENTIFIED BY clause or provide an empty password, the user has
no password. This is very insecure.
If NO_AUTO_CREATE_USER is enabled and the account does not exist, GRANT fails and does not create the account unless
the IDENTIFIED BY clause is given to provide a nonempty password.
Important : GRANT may be recorded in server logs or in a history file such as ~/.mysql_history, which means that cleartext
passwords may be read by anyone having read access to that information. See Section 6.1.2, “Keeping Passwords Secure”.
Other Account Characteristics
The WITH clause is used for several purposes:
 To enable a user to grant privileges to other users
 To specify resource limits for a user
 To specify whether and how a user must use secure connections to the server
The WITH GRANT OPTION clause gives the user the ability to give to other users any privileges the user has at the specified
privilege level. You should be careful to whom you give the GRANT OPTION privilege because two users with different
privileges may be able to combine privileges!
You cannot grant another user a privilege which you yourself do not have; the GRANT OPTION privilege enables you to
assign only those privileges which you yourself possess.
Be aware that when you grant a user the GRANT OPTION privilege at a particular privilege level, any privileges the user
possesses (or may be given in the future) at that level can also be granted by that user to other users. Suppose that you
grant a user the INSERT privilege on a database. If you then grant the SELECT privilege on the database and specify WITH
GRANT OPTION, that user can give to other users not only the SELECT privilege, but also INSERT. If you then grant the
UPDATE privilege to the user on the database, the user can grant INSERT, SELECT, and UPDATE.
For a nonadministrative user, you should not grant the ALTER privilege globally or for the mysql database. If you do that,
the user can try to subvert the privilege system by renaming tables!
For additional information about security risks associated with particular privileges, see Section 6.2.1, “Privileges Provided
by MySQL”.
Several WITH clause options specify limits on use of server resources by an account:


The MAX_QUERIES_PER_HOUR count, MAX_UPDATES_PER_HOUR count, and MAX_CONNECTIONS_PER_HOUR
count limits restrict the number of queries, updates, and connections to the server permitted to this account during
any given one-hour period. (Queries for which results are served from the query cache do not count against the
MAX_QUERIES_PER_HOUR limit.) If count is 0 (the default), this means that there is no limitation for the account.
The MAX_USER_CONNECTIONS count limit, implemented in MySQL 5.0.3, restricts the maximum number of
simultaneous connections to the server by the account. A nonzero count specifies the limit for the account explicitly.
If count is 0 (the default), the server determines the number of simultaneous connections for the account from the
global value of the max_user_connections system variable. If max_user_connections is also zero, there is no limit
for the account.
To specify resource limits for an existing user without affecting existing privileges, use GRANT USAGE at the global level
(ON *.*) and name the limits to be changed. For example:
GRANT USAGE ON *.* TO ...
WITH MAX_QUERIES_PER_HOUR 500 MAX_UPDATES_PER_HOUR 100;
Limits not specified retain their current values.
For more information on restricting access to server resources, see Section 6.3.4, “Setting Account Resource Limits”.
MySQL can check X509 certificate attributes in addition to the usual authentication that is based on the user name and
password. To specify SSL-related options for a MySQL account, use the REQUIRE clause of the GRANT statement. (For
background information on the use of SSL with MySQL, see Section 6.3.6, “Using SSL for Secure Connections”.)
There are a number of different possibilities for limiting connection types for a given account:

REQUIRE NONE indicates that the account has no SSL or X509 requirements. This is the default if no SSL-related
REQUIRE options are specified. Unencrypted connections are permitted if the user name and password are valid.

However, encrypted connections can also be used, at the client's option, if the client has the proper certificate and
key files. That is, the client need not specify any SSL command options, in which case the connection will be
unencrypted. To use an encrypted connection, the client must specify either the --ssl-ca option, or all three of the -ssl-ca, --ssl-key, and --ssl-cert options.
The REQUIRE SSL option tells the server to permit only SSL-encrypted connections for the account.

GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SSL;
To connect, the client must specify the --ssl-ca option to authenticate the server certificate, and may additionally
specify the --ssl-key and --ssl-cert options. If neither --ssl-ca option nor --ssl-capath option is specified, the client does
not authenticate the server certificate.

REQUIRE X509 means that the client must have a valid certificate but that the exact certificate, issuer, and subject
do not matter. The only requirement is that it should be possible to verify its signature with one of the CA certificates.

GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE X509;
To connect, the client must specify the --ssl-ca, --ssl-key, and --ssl-cert options. This is also true for ISSUER and SUBJECT
because those REQUIRE options imply X509.

REQUIRE ISSUER 'issuer' places the restriction on connection attempts that the client must present a valid X509
certificate issued by CA 'issuer'. If the client presents a certificate that is valid but has a different issuer, the server
rejects the connection. Use of X509 certificates always implies encryption, so the SSL option is unnecessary in this
case.

GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'
REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/
O=MySQL Finland AB/CN=Tonu Samuel/emailAddress=tonu@example.com';
The 'issuer' value should be entered as a single string.
Note: If MySQL is linked against a version of OpenSSL older than 0.9.6h, use Email rather than emailAddress in
the 'issuer' value.

REQUIRE SUBJECT 'subject' places the restriction on connection attempts that the client must present a valid X509
certificate containing the subject subject. If the client presents a certificate that is valid but has a different subject,
the server rejects the connection.

GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'
REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/O=MySQL demo client certificate/
CN=Tonu Samuel/emailAddress=tonu@example.com';
The 'subject' value should be entered as a single string. MySQL does a simple string comparison of this value to the
value in the certificate, so lettercase and component ordering must be given exactly as present in the certificate.
Note: Regarding emailAddress, see the note in the description of REQUIRE ISSUER.

REQUIRE CIPHER 'cipher' is needed to ensure that ciphers and key lengths of sufficient strength are used. SSL itself
can be weak if old algorithms using short encryption keys are used. Using this option, you can ask that a specific
cipher method is used for a connection.

GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'
REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';
The SUBJECT, ISSUER, and CIPHER options can be combined in the REQUIRE clause like this:
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret'
REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/O=MySQL demo client certificate/
CN=Tonu Samuel/emailAddress=tonu@example.com'
AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
O=MySQL Finland AB/CN=Tonu Samuel/emailAddress=tonu@example.com' AND CIPHER 'EDH-RSA-DES-CBC3-SHA';
The order of the options does not matter, but no option can be specified twice. The AND keyword is optional between
REQUIRE options.
If you are using table, column, or routine privileges for even one user, the server examines table, column, and routine
privileges for all users and this slows down MySQL a bit. Similarly, if you limit the number of queries, updates, or connections
for any users, the server must monitor these values.
MySQL and Standard SQL Versions of GRANT
The biggest differences between the MySQL and standard SQL versions of GRANT are:






MySQL associates privileges with the combination of a host name and user name and not with only a user name.
Standard SQL does not have global or database-level privileges, nor does it support all the privilege types that
MySQL supports.
MySQL does not support the standard SQL UNDER privilege, and does not support the TRIGGER privilege until
MySQL 5.1.6.
Standard SQL privileges are structured in a hierarchical manner. If you remove a user, all privileges the user has
been granted are revoked. This is also true in MySQL 5.0.2 and up if you use DROP USER. Before 5.0.2, the
granted privileges are not automatically revoked; you must revoke them yourself. See Section 13.7.1.2, “DROP
USER Syntax”.
In standard SQL, when you drop a table, all privileges for the table are revoked. In standard SQL, when you
revoke a privilege, all privileges that were granted based on that privilege are also revoked. In MySQL, privileges
can be dropped only with explicit DROP USER or REVOKE statements or by manipulating the MySQL grant tables
directly.
In MySQL, it is possible to have the INSERT privilege for only some of the columns in a table. In this case, you can
still execute INSERT statements on the table, provided that you insert values only for those columns for which you
have the INSERT privilege. The omitted columns are set to their implicit default values if strict SQL mode is not
enabled. In strict mode, the statement is rejected if any of the omitted columns have no default value. (Standard
SQL requires you to have the INSERT privilege on all columns.) Section 5.1.7, “Server SQL Modes”, discusses strict
mode. Section 11.1.7, “Data Type Default Values”, discusses implicit default values.
13.7.1.4. RENAME USER Statement
 Renames existing MySQL accounts.
Syntax
: RENAME USER
old_user TO new_user [, old_user TO new_user] ...
Notations:
 To use it, you must have the global CREATE USER privilege or the UPDATE privilege for the mysql database. An
error occurs if any old account does not exist or any new account exists. Each account name uses the format
described in Section 6.2.3, “Specifying Account Names”.
 If you specify only the user name part of the account name, a host name part of '%' is used.
 RENAME USER causes the privileges held by the old user to be those held by the new user. However, RENAME
USER does not automatically drop or invalidate databases or objects within them that the old user created. This
includes stored programs or views for which the DEFINER attribute names the old user. Attempts to access such
objects may produce an error if they execute in definer security context. (For information about security context,
see Section 18.5, “Access Control for Stored Programs and Views”.)
 The privilege changes take effect as indicated in Section 6.2.6, “When Privilege Changes Take Effect”.

The RENAME USER statement was added in MySQL 5.0.2.
Example
: RENAME USER 'jeffrey'@'localhost' TO 'jeff'@'127.0.0.1';
13.7.1.5. REVOKE Statement
 Enables system administrators to revoke privileges from MySQL accounts.

Syntax:
REVOKE
priv_type [(column_list)]
[, priv_type [(column_list)]] ...
ON [object_type] priv_level
FROM user [, user] ...
REVOKE ALL PRIVILEGES, GRANT OPTION
FROM user [, user] ...
Notations:
 Each account name uses the format described in Section 6.2.3, “Specifying Account Names”.
 If you specify only the user name part of the account name, a host name part of '%' is used.
 For details on the levels at which privileges exist, the permissible priv_type and priv_level values,
and the syntax for specifying users and passwords, see Section 13.7.1.3, “GRANT Syntax”
 To use the first REVOKE syntax, you must have the GRANT OPTION privilege, and you must have
the privileges that you are revoking.
 To revoke all privileges, use the second syntax, which drops all global, database, table, column,
and routine privileges for the named user or users: REVOKE ALL PRIVILEGES, GRANT
OPTION FROM user [, user] ...
 To use this REVOKE syntax, you must have the global CREATE USER privilege or the UPDATE
privilege for the mysql database.
 REVOKE removes privileges, but does not drop mysql.user table entries. To remove a user account
entirely, use DROP USER (see Section 13.7.1.2, “DROP USER Syntax”) or DELETE.
 If the grant tables hold privilege rows that contain mixed-case database or table names and the
lower_case_table_names system variable is set to a nonzero value, REVOKE cannot be used to
revoke these privileges. It will be necessary to manipulate the grant tables directly. (GRANT will
not create such rows when lower_case_table_names is set, but such rows might have been created
prior to setting the variable.)
 When successfully executed from the mysql program, REVOKE responds with Query OK, 0 rows
affected. To determine what privileges result from the operation, use SHOW GRANTS. See
Section 13.7.5.17, “SHOW GRANTS Syntax”.
Example: REVOKE INSERT ON *.* FROM 'jeffrey'@'localhost';
13.7.1.6. SET
PASSWORD Statement
Syntax:
SET PASSWORD [FOR user] = {
PASSWORD('cleartext password') | OLD_PASSWORD('cleartext password')
| 'encrypted password'
}
The SET PASSWORD statement assigns a password to an existing MySQL user account. In MySQL 5.0,
enabling the read_only system variable does not prevent use of SET PASSWORD.
If the password is specified using the PASSWORD() or OLD_PASSWORD() function, the cleartext
(unencrypted) password should be given as the argument to the function, which hashes the password and
returns the encrypted password string. If the password is specified without using either function, it should be
the already encrypted password value as a literal string. In all cases, the encrypted password string must
be in the format required by the authentication method used for the account.
With no FOR user clause, this statement sets the password for the current user. (To see which account the
server authenticated you as, invoke the CURRENT_USER() function.) Any client who successfully connects to
the server using a nonanonymous account can change the password for that account.
With a FOR user clause, this statement sets the password for the named user. You must have the UPDATE
privilege for the mysql database to do this. The user account name uses the format described in
Section 6.2.3, “Specifying Account Names”. The user value should be given as 'user_name'@'host_name',
where 'user_name' and 'host_name' are exactly as listed in the User and Host columns of the mysql.user
table row. (If you specify only a user name, a host name of '%' is used.) For example, to set the password
for an account with User and Host column values of 'bob' and '%.example.org', write the statement like
this:
SET PASSWORD FOR 'bob'@'%.example.org' = PASSWORD('cleartext password');
That is equivalent to the following statements:
UPDATE mysql.user SET Password=PASSWORD('cleartext password')
WHERE User='bob' AND Host='%.example.org';
FLUSH PRIVILEGES;
Another way to set the password is to use GRANT:
GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';
The old_passwords system variable value determines the hashing method used by PASSWORD(). If you
specify the password using that function and SET PASSWORD rejects the password as not being in the correct
format, it may be necessary to set old_passwords to change the hashing method. For descriptions of the
permitted values, see Section 5.1.4, “Server System Variables”.
For more information about setting passwords, see Section 6.3.5, “Assigning Account Passwords”
Important: SET PASSWORD may be recorded in server logs or in a history file such as ~/.mysql_history,
which means that cleartext passwords may be read by anyone having read access to that information. See
Section 6.1.2, “Keeping Passwords Secure”.
Caution: If you are connecting to a MySQL 4.1 or later server using a pre-4.1 client program, do not change
your password without first reading Section 6.1.2.4, “Password Hashing in MySQL”. The default password
hashing format changed in MySQL 4.1, and if you change your password, it might be stored using a hashing
format that pre-4.1 clients cannot generate, thus preventing you from connecting to the server afterward.
If you are using MySQL Replication, be aware that, currently, a password used by a replication slave as
part of a CHANGE MASTER TO statement is effectively limited to 32 characters in length; the password can
be longer, but any excess characters are truncated. This is not due to any limit imposed by the MySQL Server
generally, but rather is an issue specific to MySQL Replication. (For more information, see Bug #43439.)
Copyright © 1997, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices