How to fix ERROR 1133: Can't find matching row in user table in MySQL

Run the following query to list all existing user@host combinations:

SELECT User, Host FROM mysql.user ORDER BY User, Host;

This shows the exact user@host rows available. Compare this list to the user you're trying to modify. Note the exact capitalization and host value.

If the user is not in the list, create it first using CREATE USER:

CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'StrongP@ss!';

Replace 'app_user' and 'localhost' with your actual username and host. The host can be:
- 'localhost' for local connections
- '%' for all hosts (security note: use specific IPs in production)
- A specific IP like '192.168.1.10'

After creating the user, you can then run your ALTER USER, SET PASSWORD, or GRANT statement.

If the user is in the list but your command still fails, the host mismatch is likely the cause.

For example, if the table shows 'app_user'@'localhost' but you're running:

ALTER USER 'app_user'@'%' IDENTIFIED BY 'newpass';  -- Wrong host

Instead, use the correct host:

ALTER USER 'app_user'@'localhost' IDENTIFIED BY 'newpass';  -- Correct

Or, if you need to support multiple hosts, create a separate account:

CREATE USER 'app_user'@'%' IDENTIFIED BY 'newpass';

To avoid this error in automated scripts or migrations, use IF EXISTS and IF NOT EXISTS clauses:

CREATE USER IF NOT EXISTS 'dev'@'%' IDENTIFIED BY 'SecurePass123';
ALTER USER IF EXISTS 'dev'@'%' IDENTIFIED BY 'UpdatedPass456';

This way, if the user doesn't exist, it's created first. If it does exist, it's updated. No error either way.

If you encounter this error after restoring a MySQL backup:

1. Verify the mysql.user table was restored:

SELECT COUNT(*) FROM mysql.user;

2. If there are very few rows or the user is missing, manually recreate the accounts:

CREATE USER 'restored_user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON mydb.* TO 'restored_user'@'localhost';

3. Flush privileges to ensure changes take effect:

FLUSH PRIVILEGES;

Note: FLUSH PRIVILEGES only reloads the in-memory grant tables. It does NOT create missing users—you must CREATE USER explicitly.