Introduction

TiDB is MySQL-compatible at the SQL layer, but that does not mean MySQL system tables are safe to copy into it blindly. If you accidentally import MySQL's user metadata into TiDB or lose access because of credentials, the safest recovery path is to recreate or reset users using TiDB's own SQL and recovery procedures, not to treat system tables as ordinary application data.

Why Importing the MySQL User Table Is Dangerous

Application tables are one thing; system tables are different. The mysql schema contains authentication and privilege metadata, and those internals are not something you should migrate by generic dump-and-load logic unless the target system explicitly documents it.

When people import MySQL user data into TiDB accidentally, the common risks are:

• authentication data that does not match the expected format or semantics
• overwritten privilege state
• inconsistent user definitions
• loss of confidence about which accounts are actually valid

Even though TiDB speaks MySQL-compatible SQL, the safe operational assumption is still: do not copy system-account tables between products as if they were ordinary business tables.

Safer Migration Rule

When migrating from MySQL to TiDB:

• migrate application schemas and data intentionally
• exclude system-account tables from generic imports
• recreate users and grants using SQL on the TiDB side

That keeps authentication state under TiDB's control instead of inheriting opaque metadata from another system.

Recreate Users Explicitly

If the imported user metadata cannot be trusted, recreate the accounts you actually need.

CREATE USER 'app_user'@'%' IDENTIFIED BY 'new_strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON appdb.* TO 'app_user'@'%';

For administrators:

CREATE USER 'admin_user'@'%' IDENTIFIED BY 'another_strong_password';
GRANT ALL PRIVILEGES ON *.* TO 'admin_user'@'%';

The exact privileges should match your real operational needs, not just copy whatever happened to be in the source system.

If You Still Have a Privileged Login

If you can still log in through another administrative account, password recovery is straightforward. Reset the affected user with ALTER USER.

ALTER USER 'app_user'@'%' IDENTIFIED BY 'reset_password_here';

Then verify the account works before making further changes.

This is the best-case scenario because you can recover access without touching lower-level metadata.

If You Do Not Have a Working Administrative Account

At that point, the right answer depends on how TiDB is deployed and what recovery access you have to the cluster. The important principle is still the same:

• do not try to "repair" authentication by manually editing imported MySQL system rows
• follow the documented TiDB administrative recovery path for your deployment

In operational terms, that usually means restoring controlled administrative access first, then recreating the users and grants you want to keep.

Clean-Up After an Accidental Import

Once access is restored, do a structured clean-up:

1. Identify which accounts should exist.
2. Recreate or reset them with explicit SQL.
3. Reapply grants intentionally.
4. Remove any user records or privilege state that came from the accidental import and should not remain.
5. Validate logins and privilege boundaries with real tests.

If this happened during migration, update the migration process so system-account tables are excluded next time.

Backups and Audit Matter

Before making large privilege repairs, take a backup or snapshot if your deployment process supports it. Authentication recovery is exactly the kind of change that deserves an audit trail because it affects who can access the cluster and what they can do.

Also document:

• which users were recreated
• which passwords were rotated
• which grants were reapplied

That turns a one-time emergency into a repeatable operational runbook.

Common Pitfalls

The biggest mistake is assuming MySQL compatibility means TiDB system-account metadata can be copied and trusted wholesale. Compatibility at the SQL layer is not permission to treat internal privilege tables as portable application data.

Another issue is trying to fix broken authentication by editing low-level system rows manually. That is risky, hard to audit, and easy to get wrong.

Developers also forget to review grants after resetting passwords. Restoring access is only part of the job; privilege correctness matters too.

Finally, migration scripts that include the entire mysql schema are a recurring source of trouble. Excluding system-account data should be a deliberate migration rule.

Summary

• Do not treat MySQL user tables as ordinary data to import into TiDB.
• Recreate users and grants on the TiDB side with explicit SQL.
• If you still have admin access, reset forgotten passwords with ALTER USER.
• If admin access is gone, recover it through TiDB's documented administrative path instead of manual system-table edits.
• Update migration processes so system-account tables are excluded in the future.