13.7.1.1 CREATE USER Syntax

CREATE USER user_specification [, user_specification] ...

user_specification:
    user [ identified_option ]

identified_option: {
    IDENTIFIED BY 'auth_string'
  | IDENTIFIED BY PASSWORD 'hash_string'
}

The CREATE USER statement creates new MySQL accounts. An error occurs if you try to create an account that already exists.

To use CREATE USER, you must have the global CREATE USER privilege or the INSERT privilege for the mysql database. In MySQL 5.1 and later, when the read_only system variable is enabled, CREATE USER additionally requires the SUPER privilege.

For each account, CREATE USER creates a new row in the mysql.user table with no privileges. Depending on the syntax used, CREATE USER may also assign the account a password.

Each user_specification clause consists of an account name and information about how authentication occurs for clients that use the account. This part of CREATE USER syntax is shared with GRANT, so the description here applies to GRANT as well.

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.

CREATE USER examples:

• To enable the user to connect with no password, include no IDENTIFIED BY clause:

  CREATE USER 'jeffrey'@'localhost';
  

• To assign a password, use IDENTIFIED BY with the literal cleartext password value:

  CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'mypass';
  

• To avoid specifying the cleartext 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 on the client side in a history file such as ~/.mysql_history, which means that cleartext passwords may be read by anyone having read access to that information. For information about password logging in the server logs, see Section 6.1.2.3, “Passwords and Logging”. For similar information about client-side logging, see Section 4.5.1.3, “mysql Logging”.