How to Fix MySQL Error 1044: Access Denied for User to Database

MySQL error 1044 surfaces as ERROR 1044 (42000): Access denied for user 'username'@'host' to database 'dbname'. The SQLSTATE code is 42000 (syntax error or access rule violation class). The condition name is ER_DBACCESS_DENIED_ERROR. It means the authenticated MySQL user does not hold the necessary privilege on the named database to perform the requested operation.

What This Error Means

SQLSTATE 42000 covers both syntax errors and access violations. Error 1044 specifically fires when MySQL's privilege-checking layer rejects a database-level operation — typically USE dbname, CREATE DATABASE, or any statement issued against a database the user has no grant on at all.

MySQL privileges form a hierarchy: global (server-wide), database-level, table-level, column-level, and routine-level. Error 1044 is raised at the database level. The user may have been granted table-level or column-level privileges on objects inside the database, but if no database-level or global grant covers the attempted operation, MySQL rejects it with 1044 before even evaluating lower-level grants for certain commands.

This error is distinct from error 1045 (ER_ACCESS_DENIED_ERROR), which fires during authentication when the host/password combination is wrong. Error 1044 only occurs after a successful login — the user authenticated fine but the account lacks permission on the target database.

Common Causes

1. No grant exists for the database. The user account was created but never granted any privileges on the target database. This is the most common cause, especially after CREATE USER without a subsequent GRANT.
2. Wrong host qualifier on the grant. A grant was issued for 'user'@'localhost' but the application connects as 'user'@'192.168.1.10' (or 'user'@'%'). MySQL treats these as different accounts — the connecting account may not have any database grant.
3. Connecting to the wrong database name. A typo in the connection string causes MySQL to check for grants on a database that was never explicitly granted. The database may exist but the account was only granted access under the correctly spelled name.
4. Revoked or never-flushed grants. A REVOKE statement removed the privilege, or — in older MySQL 5.x deployments — FLUSH PRIVILEGES was not run after a manual edit to the mysql.db grant table.
5. Trying to CREATE DATABASE without the CREATE privilege. Users connecting to create a new database need either the global CREATE privilege or explicit permission to create that database name. Without it, MySQL raises 1044 on CREATE DATABASE.
6. Replication or migration left users without matching grants. After a dump/restore or a replication topology change, user accounts may exist on the new host but their grants were not re-applied.

How to Fix ER_DBACCESS_DENIED_ERROR

1. Verify what grants the user currently holds.

   SHOW GRANTS FOR 'username'@'host';
   

   If no database-level grant appears for the target database, that confirms the cause.

2. Grant the required privileges on the database.

   For a typical application user that needs read/write access:

   GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER
     ON dbname.*
     TO 'username'@'host';
   

   For a read-only reporting user:

   GRANT SELECT ON dbname.* TO 'username'@'host';
   

   For a user that needs to create the database itself:

   GRANT CREATE ON *.* TO 'username'@'host';
   -- or, more narrowly:
   GRANT CREATE ON `dbname`.* TO 'username'@'host';
   

3. Make sure the host qualifier matches exactly how the user connects.

   Check the host string in your connection URL, then confirm it matches the grant:

   SELECT User, Host FROM mysql.user WHERE User = 'username';
   

   If the user connects from any host, grant to 'username'@'%' instead of 'username'@'localhost'.

4. Apply privileges immediately (MySQL 5.x).

   On MySQL 5.x, if grants were applied by directly editing the mysql.db table, reload them:

   FLUSH PRIVILEGES;
   

   On MySQL 8.x, GRANT and REVOKE statements take effect immediately without a flush.

5. For a minimal-privilege pattern, use specific grants rather than ALL PRIVILEGES.

   Granting ALL PRIVILEGES ON dbname.* works but gives the user administrative abilities (DROP DATABASE, GRANT OPTION, etc.). Prefer enumerating only the privileges the application actually needs.

6. After a migration, re-apply grants from the source.

   Use mysqldump --no-data on mysql.* tables, or use pt-show-grants (Percona Toolkit) to export and replay grants on the destination server:

   pt-show-grants --user=root --ask-pass | mysql -u root -p -h new-host
   

Additional Information

• SQLSTATE 42000 (syntax error or access violation) groups several related privilege errors. Error 1044 is database-level access; error 1142 is table-level (ER_TABLEACCESS_DENIED_ERROR); error 1143 is column-level (ER_COLUMNACCESS_DENIED_ERROR).
• MySQL 8.0 changed how roles interact with database grants. A user granted a role that has database-level privileges must have the role active (either via SET ROLE or through activate_all_roles_on_login = ON) — otherwise the effective privilege set is empty and 1044 can occur even if the role includes the necessary grants.
• Most application drivers (JDBC, mysqlclient, mysql2 for Node.js, PyMySQL) surface this as a generic database exception with the message text preserved. Check the driver's exception type: JDBC throws java.sql.SQLException with error code 1044; the Go go-sql-driver/mysql driver surfaces it as *mysql.MySQLError with Number: 1044.
• ORMs that run schema migrations (Flyway, Liquibase, Rails ActiveRecord) will abort at startup and report this error if the migration user lacks CREATE, ALTER, or DROP on the target database.

Frequently Asked Questions

What is the difference between MySQL error 1044 and error 1045? Error 1045 (ER_ACCESS_DENIED_ERROR) is an authentication failure — the username, password, or host combination was rejected before a session was established. Error 1044 occurs after a successful login: the user authenticated but lacks the privilege to access a specific database. If you can log in at all but cannot USE or query a database, it is 1044, not 1045.

Does running FLUSH PRIVILEGES fix error 1044? Only in the narrow case where grants were written directly to the mysql.db table (a legacy DBA practice from MySQL 5.x). In all normal cases, GRANT and REVOKE statements are authoritative and take effect immediately — FLUSH PRIVILEGES has no effect on grants issued through SQL statements.

I granted ALL PRIVILEGES ON *.* — why am I still getting error 1044? A global ALL PRIVILEGES grant without GRANT OPTION still allows the user to access all databases. If you see 1044 with a wildcard grant in place, check that the host qualifier matches exactly how the application is connecting. Also verify the grant was issued for the same MySQL account the application uses — run SELECT CURRENT_USER() from an application session to see the resolved account.

Can MySQL error 1044 occur inside a stored procedure or event? Yes. Stored routines execute with the privileges of the definer by default (SQL SECURITY DEFINER). If the definer account no longer has the required database grant, any caller will trigger 1044 when the routine tries to access that database. Fix by re-granting the necessary privileges to the definer account or by changing the routine to SQL SECURITY INVOKER.