Introduction

In MySQL 8, the root account usually starts with very high privileges already. So the real question is often not “how do I make root powerful,” but “how do I inspect or adjust the account’s host access and privilege scope safely without breaking the security model.”

The Basic Grant Statement

If you truly need to grant all privileges to a root account, the classic pattern is:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

This grants every privilege on every database and table to the local root account and allows it to grant privileges to others.

In MySQL 8, FLUSH PRIVILEGES is usually not necessary after normal GRANT statements because MySQL updates grant tables immediately, but many administrators still include it out of habit. The important part is the GRANT itself.

Remember That Host Matters

In MySQL, 'root'@'localhost' and 'root'@'%' are not the same account. Privileges are attached to the full user-plus-host identity.

So this account:

'root'@'localhost'

is different from:

'root'@'127.0.0.1'

and different again from:

'root'@'%'

If the login path is failing or the privileges seem inconsistent, check which host entry the client is actually matching.

Create the Account First if Needed

MySQL 8 no longer creates users implicitly through GRANT. If the account does not exist, create it first:

CREATE USER 'root'@'localhost' IDENTIFIED BY 'strong-password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;

For an existing account, you may only need ALTER USER to reset authentication or password settings:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'strong-password';

That distinction matters because older tutorials often assume GRANT can create the user. In MySQL 8, that is no longer the model.

Be Very Careful with Remote Root Access

You can grant full privileges to 'root'@'%', but that is usually a bad operational choice:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;

Technically this works if the account exists and the server allows remote access. Operationally, it expands your attack surface and violates the principle of least privilege.

A better practice is:

• keep root local when possible
• create separate admin accounts for remote administration
• restrict remote hosts explicitly instead of using %

That gives you auditability and reduces blast radius.

Verify the Result

After changing privileges, inspect them directly:

SHOW GRANTS FOR 'root'@'localhost';

This is the fastest way to confirm what the server thinks the account can do.

If login still fails, the problem may not be privileges at all. It may be authentication plugin configuration, host matching, bind address, or firewall settings.

Common Pitfalls

The biggest mistake is granting privileges to the wrong host-qualified account. MySQL user identities include the host, and that detail changes everything.

Another issue is assuming GRANT will create the account in MySQL 8. It will not. Use CREATE USER first when necessary.

Developers also often expose remote root access when a dedicated admin account would be safer. Full remote root privileges are rarely the best design.

Finally, do not confuse privilege problems with connection problems. A refused remote login can come from server networking or authentication settings even when the grants themselves are correct.

Summary

• The core statement is GRANT ALL PRIVILEGES ON *.* TO 'root'@'host' WITH GRANT OPTION.
• In MySQL 8, create the account explicitly if it does not already exist.
• Host-qualified accounts matter as much as usernames.
• Verify the result with SHOW GRANTS.
• Avoid broad remote root access unless there is a compelling operational reason.