The designated MySQL server administrator has only GRANT USAGE and cannot access the databases.

Hello @Mohammed Aleem

What you're seeing is not the expected state for the MySQL Flexible Server administrator. GRANT USAGE ON . effectively means the account has no meaningful database privileges. Microsoft's documented Flexible Server administrator normally has privileges including SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, SHOW DATABASES, CREATE USER, and others.

The key detail is that you've already reset the password in the Azure Portal. Microsoft specifically documents that resetting the server administrator password should also reset the administrator privileges to their default settings. This is the recommended recovery method when administrator privileges have accidentally been revoked.

Since that operation completed, but:

SHOW GRANTS;

still returns only:

GRANT USAGE ON *.* ...

and:

SHOW DATABASES;

only shows information_schema and performance_schema. I would treat this as a server-side administrator metadata/provisioning problem, not simply a password issue.

Before escalating, I would verify that you're actually connected as the administrator identity Azure thinks you're using:

SELECT USER(), CURRENT_USER();
SHOW GRANTS;
SELECT user, host FROM mysql.user;

USER() shows the identity supplied by the client, while CURRENT_USER() is particularly important because it identifies the MySQL account actually used for privilege checking. If these differ unexpectedly, you may be authenticating as another MySQL account.

Also confirm the Server admin login name shown on the Flexible Server's Overview/Properties page matches the account you're testing. Microsoft recommends using the administrator shown there when connecting to the server.

If CURRENT_USER() confirms the correct server administrator and another Portal password reset still leaves it with only USAGE, I wouldn't try manually granting the administrator privileges back. Azure Database for MySQL is a managed service, and privileges such as SUPER aren't exposed to customers; the underlying azure_superuser account is Microsoft-managed.

The CLI error:

ProvisionNotSupportedForRegion

is also significant. If the Portal operation and CLI management operation behave differently, include that error in the support case rather than assuming it is related to MySQL permissions.

At this point, I recommend opening an Azure support request under Azure Database for MySQL Flexible Server and providing:

• Subscription ID and server/resource name
• Azure region
• Administrator username shown in the Portal
• Output of SELECT USER(), CURRENT_USER();
• Output of SHOW GRANTS;
• Result/time of the Portal Reset password operation
• Full ProvisionNotSupportedForRegion CLI error, including correlation/request ID if available

Microsoft's documentation confirms that the password-reset operation should restore the server administrator's default privileges, so if it doesn't, Microsoft Support should investigate the server's administrator metadata/state.

Sharing these references with you:

Microsoft - Manage Azure Database for MySQL Flexible Server

Microsoft - Create and manage MySQL users and administrator privileges

I would not delete or restore the server yet, especially if this is production. The symptoms justify having Microsoft inspect the managed-service side before taking a disruptive recovery action.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.