How to Change a Password in a MySQL or MariaDB User: Every Method Explained

20 June 2026
by: David Okafor
in: MySQL/MariaDB
Tags: alter user, database security, MariaDB, MySQL, user management
note: no comments

Changing the password for a MySQL or MariaDB user is one of the most common administrative tasks you will perform on a database server, yet it trips up far more administrators than it should. The reason is simple: there are several ways to do it, the “correct” method has changed across versions, and one popular legacy approach can quietly lock you out of your own server.

Table of Contents

To change a password in a MySQL user on a modern installation, run `ALTER USER ‘username’@’host’ IDENTIFIED BY ‘new_password’;` and then `FLUSH PRIVILEGES;`. That single statement is the recommended approach on MySQL 5.7.6 and later, MySQL 8.0, and MariaDB 10.2 and later. The rest of this guide explains every other method, when each one applies, and how to recover when you have forgotten the password entirely.

Key Takeaways
• `ALTER USER … IDENTIFIED BY` is the modern, correct way to change a password on MySQL 5.7.6+, 8.0, and MariaDB 10.2+.
• `SET PASSWORD FOR` is a valid alternative and works across most versions.
• The legacy `UPDATE mysql.user` trick is deprecated and risky — it can skip password hashing or lock you out on newer versions.
• Use `mysqladmin` for quick command-line changes of your own password.
• A forgotten root password is recovered by starting MySQL with `–skip-grant-tables`.
• MySQL 8 defaults to `caching_sha2_password`, which can break older clients expecting `mysql_native_password`.

Why Are There So Many Ways to Change a MySQL Password?

MySQL and MariaDB have evolved over more than two decades, and password management has been refactored several times for security reasons. Early versions stored credentials in a plain `mysql.user` table that administrators edited directly. Modern versions abstract that storage behind dedicated SQL statements that handle hashing, validation, and plugin selection automatically.

The practical consequence is that the method you find in an old forum post may not behave the way you expect on a current server. Using the wrong method can leave a password stored unhashed, apply an incompatible authentication plugin, or fail silently. Choosing the right statement for your version is therefore a security decision, not just a syntax preference.

MariaDB forked from MySQL and shares much of this history, so most statements are interchangeable. Where behavior differs — particularly around authentication plugins — we will call it out explicitly.

How Do You Change a Password With ALTER USER?

The `ALTER USER` statement is the canonical, supported way to change a password on any modern server. It is explicit, readable, and handles hashing for you.

“`sql ALTER USER ‘appuser’@’localhost’ IDENTIFIED BY ‘StrongP@ssw0rd!2026’; FLUSH PRIVILEGES; “`

A few details matter here:

The `’appuser’@’localhost’` part is the full account identifier. MySQL treats `’appuser’@’localhost’` and `’appuser’@’%’` as two distinct accounts, so make sure you are changing the right one.
The host portion is required. If you omit it, the server assumes `%` (any host), which may not be the account you intended.
Wrap the password in single quotes and escape any special characters appropriately for your shell if you are passing it through a script.

On MySQL 8, you can also specify the authentication plugin in the same statement, which is useful when an application cannot handle the newer default:

“`sql ALTER USER ‘appuser’@’localhost’ IDENTIFIED WITH mysql_native_password BY ‘StrongP@ssw0rd!2026’; “`

`ALTER USER` is available from MySQL 5.7.6, MySQL 8.0, and MariaDB 10.2 onward. If your server predates these versions, fall back to `SET PASSWORD`.

How Do You Use SET PASSWORD FOR?

`SET PASSWORD` is the long-standing alternative and remains valid. On modern MySQL it accepts a plaintext value that the server hashes automatically:

“`sql SET PASSWORD FOR ‘appuser’@’localhost’ = ‘StrongP@ssw0rd!2026’; FLUSH PRIVILEGES; “`

If you want to change the password for the account you are currently logged in as, you can omit the `FOR` clause entirely:

“`sql SET PASSWORD = ‘StrongP@ssw0rd!2026’; “`

Be aware of a historical pitfall: on MySQL 5.6 and earlier, `SET PASSWORD` required wrapping the value in the `PASSWORD()` function, like `SET PASSWORD FOR ‘appuser’@’localhost’ = PASSWORD(‘secret’);`. On MySQL 5.7.6+ and 8.0, the `PASSWORD()` function is deprecated or removed, and you pass the plaintext value directly. Using the old syntax on a new server will throw an error. This version split is the single most common cause of “why doesn’t this command work” confusion.

Why Is the UPDATE mysql.user Method Deprecated?

For years, administrators changed passwords by editing the system table directly:

“`sql — Legacy approach — avoid on modern servers UPDATE mysql.user SET authentication_string = PASSWORD(‘secret’) WHERE User = ‘appuser’ AND Host = ‘localhost’; FLUSH PRIVILEGES; “`

This pattern is deprecated and dangerous on current versions for several reasons:

The column changed. Older MySQL used a `Password` column; newer versions use `authentication_string`. A script written for one will silently fail or write to the wrong field on the other.
The `PASSWORD()` function is gone on MySQL 8. Without it, a raw `UPDATE` can write your password in plaintext into the table, leaving the account unusable or insecure.
Direct table edits bypass the authentication plugin logic, so the stored value may not match the format the configured plugin expects.

Here is the trap that catches experienced admins: on MySQL 8.0, running `UPDATE mysql.user SET authentication_string = ‘newpass’` does not hash the value — it stores the literal string `newpass`. Because the `caching_sha2_password` plugin then tries to validate a real login against a value that is not a valid hash, no password will ever authenticate, including the one you just “set.” You can lock yourself out of an account (or root) with a command that returns “Query OK.” Always use `ALTER USER` on modern versions; it is the only method that guarantees the value is hashed with the correct plugin. If you have already fallen into this, the `–skip-grant-tables` recovery below is your way back.

The `UPDATE mysql.user` approach should only ever be used as a last resort during a `–skip-grant-tables` recovery, and even then you should immediately convert to `ALTER USER` once you regain access.

How Do You Change a Password From the Command Line With mysqladmin?

For changing your own password without opening an interactive SQL session, `mysqladmin` is the fastest route:

“`bash mysqladmin -u appuser -p password ‘StrongP@ssw0rd!2026’ “`

You will be prompted for the current password (because of `-p`), then the new password is applied. A word of caution: passing the new password as a visible command-line argument can expose it in your shell history and in the process list (`ps aux`). On shared or production systems, prefer an interactive method or clear your history afterward.

How Do You Change the MySQL Root Password?

The root account is changed exactly like any other account — with `ALTER USER` — but it deserves its own section because the host portion and authentication plugin matter most here:

“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘A_Very_Strong_Root_Pass!’; FLUSH PRIVILEGES; “`

On MySQL 8, root often uses `caching_sha2_password` or, on some installs, the `auth_socket` plugin (which authenticates by operating-system user rather than a password). If root uses `auth_socket`, setting a password has no effect until you switch the plugin:

“`sql ALTER USER ‘root’@’localhost’ IDENTIFIED WITH caching_sha2_password BY ‘A_Very_Strong_Root_Pass!’; “`

How Do You Reset a Forgotten Root Password?

When nobody knows the root password, you bypass authentication temporarily by starting the server with grant tables disabled.

Stop the database service.

“`bash sudo systemctl stop mysql # or mariadb / mysqld “`

Start the server with authentication bypassed.

“`bash sudo mysqld_safe –skip-grant-tables –skip-networking & “`

`–skip-networking` prevents remote connections while authentication is off, which is an important security precaution.

Connect without a password and reload privileges.

“`bash mysql -u root “`

“`sql FLUSH PRIVILEGES; ALTER USER ‘root’@’localhost’ IDENTIFIED BY ‘New_Root_Pass!2026’; “`

The initial `FLUSH PRIVILEGES;` is required here because `ALTER USER` will not work while grant tables are skipped until privileges are reloaded.

Restart the service normally.

“`bash sudo systemctl restart mysql “`

On MariaDB you may need to use `SET PASSWORD` or `UPDATE mysql.user` inside the skip-grant-tables session depending on the exact version, but the recovery flow is otherwise identical. Always restart into normal mode immediately afterward — never leave a server running with grant tables disabled.

What Changed Between MySQL 5.7, MySQL 8, and MariaDB?

The biggest behavioral difference between recent versions is the default authentication plugin. MySQL 8.0 switched the default to `caching_sha2_password`, which is more secure but can break older client libraries and applications that only understand `mysql_native_password`. If an application reports authentication errors after an upgrade, switching that account’s plugin (as shown above) usually resolves it.

Method	MySQL 5.6	MySQL 5.7.6+	MySQL 8.0	MariaDB 10.2+
`ALTER USER … IDENTIFIED BY`	Not supported	Supported	Recommended	Supported
`SET PASSWORD FOR … = ‘pass’`	Needs `PASSWORD()`	Plaintext value	Plaintext value	Plaintext value
`SET PASSWORD … = PASSWORD()`	Required	Deprecated	Removed	Works (compat)
`UPDATE mysql.user`	Common (legacy)	Deprecated	Risky / unhashed	Discouraged
`mysqladmin password`	Supported	Supported	Supported	Supported
Default auth plugin	`mysql_native_password`	`mysql_native_password`	`caching_sha2_password`	`mysql_native_password`

How Do You Change a Password in phpMyAdmin or cPanel?

Not every change has to happen on the command line. Graphical tools are ideal for routine password rotation, especially for application database users.

In phpMyAdmin, open the User accounts tab, click Edit privileges next to the target user, then Change password. Enter the new value and save — phpMyAdmin issues the correct `ALTER USER` or `SET PASSWORD` statement for the server version behind the scenes.

In cPanel, navigate to MySQL Databases, find the Current Users section, click Change Password next to the user, and confirm. This is the lowest-friction way to rotate credentials for a web application and requires no SQL knowledge at all.

When Do You Actually Need FLUSH PRIVILEGES?

`FLUSH PRIVILEGES` tells the server to reload the grant tables from disk into memory. You do not need it after `ALTER USER`, `SET PASSWORD`, or `CREATE USER`, because those statements update the in-memory grant tables automatically. You do need it when you have edited the `mysql.user` table directly (the legacy method) or when you are operating inside a `–skip-grant-tables` recovery session. Running it unnecessarily does no harm, which is why so many tutorials include it by reflex.

What Are the Security Best Practices for MySQL Passwords?

Changing a password is a chance to improve your overall security posture:

Use strong, unique passwords. Favor long passphrases with mixed character classes. MySQL’s `validate_password` component can enforce a minimum policy server-wide.
Apply least privilege. A web application’s database user should never have more rights than it needs. Avoid using `root` for application connections.
Separate accounts by host. Restrict accounts to the specific hosts that need them rather than defaulting to `%`.
Rotate credentials after staff changes or suspected exposure, and never store plaintext passwords in application config files committed to version control.
Avoid passing passwords on the command line where they can be captured in history or process listings.

Simplify database user management with DarazHost

Managing MySQL and MariaDB users does not have to mean memorizing version-specific syntax. DarazHost hosting plans include cPanel and phpMyAdmin, so you can create database users and change their passwords in a few clicks — the control panel always issues the correct statement for your server version, eliminating the lock-out risks described above. For administrators who prefer the command line, our VPS plans provide full root access for `ALTER USER`, `mysqladmin`, and `–skip-grant-tables` recovery whenever you need them. And if you ever get stuck mid-recovery, our 24/7 support team can help you regain access safely.

Frequently Asked Questions

Do I need to restart MySQL after changing a user password? No. Statements like `ALTER USER` and `SET PASSWORD` take effect immediately for new connections. Existing connections keep their session until they disconnect; the next login uses the new password. A server restart is only involved when you are recovering a forgotten root password via `–skip-grant-tables`.

Why does my new password not work even though the command succeeded? The most common cause is using `UPDATE mysql.user` on MySQL 8, which stores the value unhashed so no login can ever match it. The second most common cause is changing the wrong account — remember that `’user’@’localhost’` and `’user’@’%’` are different accounts. Re-run the change with `ALTER USER` against the exact host you connect from.

What is the difference between caching_sha2_password and mysql_native_password? `caching_sha2_password` is MySQL 8’s more secure default authentication plugin. `mysql_native_password` is the older, widely compatible plugin. If an application or older client cannot authenticate after an upgrade, switch that account to `mysql_native_password` using `ALTER USER … IDENTIFIED WITH mysql_native_password BY ‘…’`.

Can I change a MySQL password without knowing the current one? Only if you have administrative privileges over the account. A user with `CREATE USER` or `UPDATE` privilege on the `mysql` schema (typically root) can reset any account with `ALTER USER`. If you have lost root itself, use the `–skip-grant-tables` recovery procedure.

Is mysqladmin safe to use for password changes? It works reliably, but passing the new password as a command-line argument exposes it in shell history and the process list. For production systems, prefer an interactive SQL session, a control panel, or clear your shell history immediately afterward.