LiveChat 
Support 
How to Change the Root Password in MySQL/MariaDB (When You Know It)
The MySQL `root` account is the single most powerful user in your database server. It can create and drop databases, manage every other user, and read or destroy all data. Knowing how to change the root password in MySQL safely and correctly is a foundational database administration skill, and the exact procedure depends on which authentication method your server uses.
This guide covers how to change the root password when you already know the current one (or can log in as root through your operating system). If you have *forgotten* the password entirely and cannot log in at all, that is a different recovery procedure using `skip-grant-tables`, covered in our sibling article linked below.
Key Takeaways
• Change the root password with `ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘newpassword’;` — the modern, recommended method on both MySQL and MariaDB.
• On Ubuntu/Debian, root often uses the auth_socket plugin (no password), so you log in with `sudo mysql` rather than a password.
• With auth_socket active, “setting a password” may first require switching the authentication plugin to `mysql_native_password` or `caching_sha2_password`.
• Always run `FLUSH PRIVILEGES;` after legacy-style changes, and restrict root to `localhost`.
• For a *forgotten* password, use the `skip-grant-tables` reset method, not this guide.
Why does the MySQL root password matter so much?
The root user is the superuser of your MySQL or MariaDB instance. A weak or exposed root password is one of the most common causes of database compromise, because automated bots constantly scan for exposed database ports and attempt common credentials.
A strong root password is your first and most important line of defense. Best practice is to combine a long, random root password with network restrictions so that root can only authenticate from `localhost`. Your applications should *never* connect as root — they should use dedicated, least-privilege accounts scoped to a single database.
How do you change the root password when you know it?
The cleanest, most portable method on modern MySQL (5.7.6+) and all current MariaDB releases is the `ALTER USER` statement. First, log in:
“`bash mysql -u root -p “`
Enter your current root password when prompted. Then run:
“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘YourNew_Strong&Password!’; FLUSH PRIVILEGES; “`
`FLUSH PRIVILEGES;` is not strictly required after `ALTER USER` on recent versions (the change applies immediately), but running it does no harm and is essential if you ever modify the grant tables directly.
The `’root’@’localhost’` part is significant: MySQL identifies users by both username and host. Changing `’root’@’localhost’` does not affect a hypothetical `’root’@’%’` (any host) account. On a properly secured server, root should exist only for `localhost`.
Changing it with mysqladmin (one-liner)
If you want to change the password without opening an interactive session, `mysqladmin` does it in a single command:
“`bash mysqladmin -u root -p password ‘YourNew_Strong&Password!’ “`
You will be prompted for the current password, after which the new one is set. This is convenient for scripts, though for security you should avoid passing the password directly on the command line (where it can appear in shell history and the process list).
The trap most people hit on Ubuntu: On a default Ubuntu or Debian MySQL install, the root account does not use a password at all — it authenticates through the auth_socket plugin (called unix_socket on MariaDB). This means root identity is verified against your operating-system user. You log in with `sudo mysql`, and there is literally no password to change. Attempts to run `mysqladmin -u root -p password …` will fail with “Access denied” because there is no password to authenticate against. Before you can *set* a password, you must first switch root’s authentication plugin — and that step trips up countless administrators who assume MySQL always uses password authentication.
How does auth_socket change things on Ubuntu/Debian?
With auth_socket, MySQL trusts the operating system: if you are the `root` OS user (via `sudo`), MySQL lets you in as the `root` database user without a password. Log in like this:
“`bash sudo mysql “`
To check which plugin root is currently using:
“`sql SELECT user, host, plugin FROM mysql.user WHERE user = ‘root’; “`
If the `plugin` column shows `auth_socket` (MySQL) or `unix_socket` (MariaDB), there is no password set. You have two valid choices:
| Goal | What to do |
|---|---|
| Keep socket auth, no password needed | Leave it as-is — log in with `sudo mysql`. This is secure for local administration. |
| Set a real password (e.g. for tooling that requires one) | Switch the plugin to password-based, then set the password. |
To switch to a conventional password on MySQL 8:
“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED WITH caching_sha2_password BY ‘YourNew_Strong&Password!’; FLUSH PRIVILEGES; “`
Or, for broader client compatibility, use `mysql_native_password`:
“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘YourNew_Strong&Password!’; FLUSH PRIVILEGES; “`
On MariaDB, the equivalent is:
“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED VIA mysql_native_password USING PASSWORD(‘YourNew_Strong&Password!’); FLUSH PRIVILEGES; “`
After this, you log in with `mysql -u root -p` and the new password — `sudo mysql` will still work too, but a password is now also valid. If you instead want to return to socket-only authentication, set the plugin back to `auth_socket` (or `unix_socket`) with no `BY` clause.
What are the step-by-step instructions?
Here is the full decision flow for changing a *known* root password:
- Determine your auth method. Try `mysql -u root -p`. If it accepts your password, you have password authentication. If it fails but `sudo mysql` works, you are on auth_socket.
- Log in using the working method (`mysql -u root -p` or `sudo mysql`).
- Confirm the plugin with `SELECT user, host, plugin FROM mysql.user WHERE user=’root’;`.
- If password-based already: run `ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘…’;`.
- If socket-based and you need a password: run the `ALTER USER … IDENTIFIED WITH
BY ‘…’` form for your server. - Flush privileges: `FLUSH PRIVILEGES;`.
- Test the new credentials in a fresh terminal: `mysql -u root -p`.
- Exit and update any credential managers or backup scripts that store the root password.
What are the security best practices for the root account?
Changing the password is only part of good root hygiene. Apply these practices alongside it:
- Use a long, random password. A passphrase or a 20+ character random string generated by a password manager is far stronger than anything memorable.
- Restrict root to localhost. Drop or never create `’root’@’%’`. Remote administration should go through SSH tunnels or a bastion, not a network-exposed root account.
- Never use root for applications. Create a per-application user with `GRANT` privileges limited to one database. This contains the blast radius if an app is compromised.
- Run `mysql_secure_installation`. This interactive script removes anonymous users, the test database, and remote root login — a quick win on fresh servers.
- Rotate credentials after staff changes or suspected exposure, and store the password in a secrets manager rather than plaintext config files.
DarazHost: managed databases or full root control, your choice
Managing the MySQL root account is straightforward once you know the auth model — but on production systems, the safest setup often *abstracts* root entirely. With DarazHost managed hosting, root-level database administration is handled for you: you create and manage database users safely through cPanel, without ever touching the MySQL root account or risking a misconfigured auth plugin. The platform keeps the server hardened and patched on your behalf.
If you need direct, hands-on control, DarazHost VPS and dedicated servers give you full root access to administer MySQL or MariaDB exactly as described in this guide — switch auth plugins, rotate the root password, and tune the server however you like. Either way, 24/7 expert support is on hand to help you recover access, secure your database, or migrate workloads without downtime.
Frequently asked questions
Do I need to restart MySQL after changing the root password? No. `ALTER USER` and `mysqladmin` apply the change immediately while the server is running. A restart is only needed for the forgotten-password recovery method that uses `skip-grant-tables`.
Why does `mysqladmin -u root -p password` say “Access denied” on Ubuntu? Because root is using the auth_socket plugin and has no password to authenticate against. Log in with `sudo mysql` and switch the plugin to `mysql_native_password` or `caching_sha2_password` first, then set a password.
What is the difference between changing and resetting the root password? *Changing* assumes you can currently authenticate (you know the password or can use `sudo mysql`). *Resetting* is for when access is lost entirely and requires starting MySQL with `skip-grant-tables` to bypass authentication. See the linked recovery guide.
Should my web application connect to MySQL as root? No. Applications should use a dedicated user with privileges limited to their own database. Using root for applications is a serious security risk because a single compromised app would expose the entire server.
Is `FLUSH PRIVILEGES;` required after `ALTER USER`? Not on modern MySQL or MariaDB — `ALTER USER` updates the in-memory grant tables automatically. It is only mandatory when you edit the `mysql.user` table directly with `UPDATE`.
