MySQL/MariaDB Administrator Credential Rotation and Root Recovery: 2026 Guide

2026 maintenance note: Rotating a known administrator credential and recovering lost administrator access are different operations. The first is a controlled change from an authenticated session; the second must follow the cloud provider, database vendor, OS distribution, or local-stack vendor's official recovery path. Use this guide only on systems you are authorized to administer.

Table of Contents

Choose the correct branch first

Current state	Correct path	Do not
A working, authorized admin session exists and a planned rotation is due	Inventory identity, plugin, consumers, and rollback; then use product/version-matched `ALTER USER`	Edit system tables or put secrets in process arguments
Ubuntu/MySQL or MariaDB uses `auth_socket`/`unix_socket`	Preserve local OS-identity authentication; determine whether a password admin is actually needed	Force a password onto the socket account
A managed database master credential is known or must be recovered	Use the provider control plane, secret-management, and audit workflow	Apply self-hosted startup flags or filesystem paths
Admin access is lost and no valid management session remains	Stop the rotation steps and use the exact product/version's official recovery documentation or support	Follow a generic privilege-bypass tutorial
XAMPP/local development stack	Identify whether the bundle actually contains MySQL or MariaDB, its version and port, and local exposure	Assume a blank password or treat XAMPP as a production deployment

phpMyAdmin is a database client, not a separate privilege system; it submits identity and actions to the server. Do not browse or edit mysql.user, mysql.global_priv, or other system tables to change a password, and do not use an old PASSWORD-function workflow.

Change gates and recovery point

Confirm the environment, data owner, authorized approver, maintenance window, and rollback owner. For a managed database, first confirm the control-plane account, Region, instance/cluster identifier, application behavior, and audit trail.
Use an existing, restore-tested capability to create a database backup or snapshot, and preserve a configuration and privilege baseline. Check replication, proxies, pools, scheduled jobs, and high-availability failover effects.
Inventory every consumer: secret manager, applications, phpMyAdmin, jobs, CI/CD, monitoring, backups, migration tools, and human operators. Applications must not use root or a cloud master user; give them separate least-privilege accounts.
Prepare the new secret under the organization's password policy, secret management, and two-person review. Do not write it to shell history, process arguments, tickets, chat, code, images, or logs.
Keep one authenticated admin session and an independent recovery route until a new session passes verification. Change exactly one account at a time.

1. Prove which server and account you reached

From the target host or an approved management network, select the client matching the installed product. Omit a value after --password so the client prompts safely; never attach a secret to the short option, use a valued long option, or store it in a password environment variable.

mysql --host=REPLACE_WITH_APPROVED_HOST --user=REPLACE_WITH_ADMIN_USER --password
mariadb --host=REPLACE_WITH_APPROVED_HOST --user=REPLACE_WITH_ADMIN_USER --password

Those are product branches, not commands to try in sequence. After connecting, identify the server read-only. CURRENT_USER() is the grant account that actually matched; USER() is the identity the client submitted:

SELECT CURRENT_USER(), USER(), @@version, @@version_comment, @@hostname, @@port;

Record the complete 'user'@'host'. 'root'@'localhost', 'root'@'127.0.0.1', and accounts with other host parts are distinct. Omitting a host can imply a broad default, so never omit it from a change statement. Confirm whether the connection uses a local socket, TCP, proxy, or managed endpoint, and verify its TLS requirements.

2. Identify product, version, and authentication plugin without hashes

Not every authentication plugin stores a password. Retrieve only nonsecret metadata; do not run or share statements that can display authentication strings or password hashes.

An authorized local administrator on MySQL 8.0/8.4 can inspect nonsecret fields for the target account:

SELECT User, Host, plugin, account_locked, password_expired
FROM mysql.user
WHERE User = 'root';

MariaDB 10.4+ uses mysql.global_priv; this query extracts plugin names without returning authentication strings:

SELECT User,
       Host,
       JSON_UNQUOTE(JSON_EXTRACT(Priv, '$.plugin')) AS primary_plugin,
       JSON_EXTRACT(Priv, '$.auth_or[*].plugin') AS alternate_plugins
FROM mysql.global_priv
WHERE User = 'root';

If the version, columns, or JSON structure do not match, do not guess syntax; use that exact version's documentation or provider metadata. MariaDB 10.4+ can configure several authentication methods for one account, and the wrong ALTER USER form can remove an existing method such as unix_socket.

3. Recognize socket authentication; do not force a password

Ubuntu-packaged MySQL commonly uses auth_socket for 'root'@'localhost'; system MariaDB 10.4+ commonly uses unix_socket. These authenticate a local OS identity and do not mean “the root password is blank.” From an authorized Ubuntu administration session, select the local socket connection for the actual product:

sudo mysql --protocol=socket --user=root
sudo mariadb --protocol=socket

If this route works and meets operational requirements, preserve it instead of switching plugins to satisfy an old tutorial. Remote administration should reach a local admin path through a controlled bastion, VPN, Session Manager, or database-provider channel. Do not create remote root, 'root'@'%', or expose the administration port to the public internet.

4. Controlled rotation when the credential is known

The SQL below is only for an authenticated, audited administration session. Replace placeholders using a secret generated and delivered by the approved secret manager; do not echo the real statement into logs. The MySQL client commonly filters history containing IDENTIFIED/PASSWORD, but you must still check client history, general-log, audit-plugin, and proxy logging policies.

MySQL 8.0/8.4

Use version-matched ALTER USER only after proving that the exact account has a supported password plugin. Omitting a new plugin avoids an accidental plugin switch:

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET';

MySQL 8.0.14+ supports dual passwords, subject to plugin, privilege, and policy constraints. Retain the old password for a staged cutover only when real legacy consumers exist and retirement has been rehearsed:

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET'
  RETAIN CURRENT PASSWORD;

After all consumers have changed and the observation window has passed, retire the secondary password on the same exact account:

ALTER USER 'root'@'localhost' DISCARD OLD PASSWORD;

Do not disable password policy for convenience. Before setting expiration, history, reuse, or failed-login locking, verify the MySQL version, global policy, break-glass account, and client handling of expired passwords so the only administrator is not locked out.

MariaDB

MariaDB syntax and multi-plugin behavior are not interchangeable with MySQL. Execute this only when the target has been proven to be a single supported password-authentication account and the exact MariaDB version's documentation confirms that this form preserves the required behavior:

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET';

Do not apply it to a MariaDB root account using unix_socket or multiple authentication methods; it can change or remove an authentication route. Have the DBA responsible for that version preserve the complete authentication rule using the official ALTER USER documentation.

5. Applications and phpMyAdmin must not use root

Create a separate application account and grant only the required schema operations. This is only a local, single-database read/write example: reduce privileges to the real need, verify the host, and replace placeholders through a secure SQL input channel.

CREATE USER 'app_user'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_APP_SECRET';
GRANT SELECT, INSERT, UPDATE, DELETE
  ON app_database.*
  TO 'app_user'@'localhost';

Do not grant global privileges or WITH GRANT OPTION. phpMyAdmin should use cookie or an organization-approved authentication mode so operators enter their own database identity; do not hardcode the root password in config.inc.php. A phpMyAdmin control user, if needed for configuration storage, is a dedicated low-privilege account, not an administrator substitute.

Apache Friends explicitly positions XAMPP as a development environment. Check the bundled engine and version in the XAMPP console, then follow that engine's official procedure; keep the database and phpMyAdmin reachable only from the local host. Even if an old bundle defaulted to a blank root password, that is not evidence about the current installation or a production baseline.

6. Verify, move consumers, and close the rollback window

Open a new session first, confirm the exact identity and a read-only operation, then verify only the administration capability you need:

mysql --host=REPLACE_WITH_APPROVED_HOST --user=root --password --execute='SELECT CURRENT_USER(), 1;'
mariadb --host=REPLACE_WITH_APPROVED_HOST --user=root --password --execute='SELECT CURRENT_USER(), 1;'

Again, choose one command by product. Then confirm the privilege baseline from the authenticated SQL session. Its output can disclose account topology, so store it in a controlled audit record and sanitize it before sharing:

SHOW GRANTS FOR 'root'@'localhost';

Update the secret manager and each consumer from the inventory, trigger controlled reconnects, and check authentication failures, pools, replication/backups/monitoring, and application health. Do not treat a database restart as a password fix: account-management statements affect new connections; restart only when an exact official recovery or configuration-change procedure requires it.

Rollback should use the retained recovery route and an approved new credential change—not an old config file or a password recovered from logs. With MySQL dual passwords, keep the old password until all consumers are verified, then run DISCARD OLD PASSWORD after the observation window. Record time, operator, exact account, product/version, reason, consumer status, and proof of old-secret disposal, but never the secret or hash.

7. Lost administrator access: stop and use official recovery

When no valid administrator session remains, this guide intentionally gives no startup flags, privilege bypass, or system-table modification steps:

Managed database: reset or rotate the master user through the provider control plane, reviewing immediate-apply, failover, proxy, replica, and secret-management behavior. Services such as Amazon RDS explicitly recommend that applications not use the master user directly.
Self-hosted MySQL: select the MySQL official root-recovery documentation matching the exact major version, OS, package source, and service manager; schedule downtime, isolate the network, protect temporary material, and review audit effects.
Self-hosted MariaDB: first determine whether an authorized local unix_socket identity still works; otherwise have the DBA responsible for that version follow the MariaDB/distribution official recovery procedure.
Ubuntu: first test the package's normal auth_socket/unix_socket route; a rejected password does not by itself mean administrator access is lost.
XAMPP: use Apache Friends/vendor recovery instructions matching the exact XAMPP release and bundled engine, only on an isolated local development machine. Back up the data directory and configuration first if the data matters.

Do not copy a generic skip-grant-tables recipe: it bypasses the privilege system, and isolation, startup, statement order, and cleanup vary by product, version, and platform. Never edit mysql.user or mysql.global_priv directly, paste an authentication hash, or edit a system table through phpMyAdmin.

Stop and escalate when

the target product, exact version, 'user'@'host', authentication plugin, or connection path cannot be proven;
the only administrator uses socket, PAM, LDAP, certificates, MFA, or MariaDB multi-plugin authentication and the plan would alter the plugin;
no recovery point, recovery route, maintenance approval, or consumer inventory exists;
replication, clustering, proxies, a managed control plane, or configuration management can overwrite the change;
the new password violates policy, the client does not support the current plugin, or testing would affect production traffic;
any step would expose a secret or hash in arguments, logs, output, tickets, or chat.

Official references

2011 original archive (not current instructions)

The complete visible source_export body is preserved below with trailing whitespace normalized and no other change. It contains unsafe command-line password passing, a blank-password assumption, phpMyAdmin system-table editing, dead HTTP images, and an obsolete function. It is historical evidence only and must not be followed.

如何修改 MySQL 用户 root 的密码


由于在创建 CONFIG 文件的时候需要输入 MySql 的用户和密码，默认用户是 root，而密码为空。很多朋友都在询问如何修改 root 的密码，以避免安全问题。其实修改密码非常简单。

方法1：
 命令行方式下输入：
 xamppmysqlbinmysqladmin -u root password(你原来的密码)
 即把数据库恢复为你原来的密码

方法2：

下面以本地服务器为例给大家提供一下步骤以供参考：

1. 在浏览器上输入 http://localhost/phpmyadmin/ 进入数据库管理界面。

2. 在左边数据库选择框内选择 mysql 数据库。然后在右边的数据库表的底部选择浏览 USER 表。
[![select-mysql](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042805ISr.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042805ISr.jpg)

3. 选择修改用户 root 的密码。
[![edit](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042807Joj.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042807Joj.jpg)

修改密码时在 FUNCTION 一栏需选择 PASSWORD

[![modify](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042808Cj0.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042808Cj0.jpg)

密码修改好以后用户再创建 CONFIG 文件，或者使用 MYSQL 数据库时就需要输入新密码了。