phpMyAdmin is a web interface to your MySQL databases. You reach it from cPanel, it opens on the database you have access to, and from there you can browse tables, run queries, export a backup and import one back.
It is also the tool with the least protection from mistakes anywhere in cPanel. A wrong query in phpMyAdmin does not ask for confirmation and cannot be undone. Everything below assumes an export exists first, because that is the difference between an error and a disaster.
Creating a database and user
Before phpMyAdmin, the database has to exist. In cPanel, open MySQL Databases.
Create a database. The name is prefixed automatically with your account name, giving something like account_wp01. Note the full name including the prefix. The prefix is the most commonly forgotten part when filling in an application's configuration.
Create a MySQL user with a strong password on the same page, and save the password immediately.
Then scroll to Add User To Database, select the user and the database, and grant ALL PRIVILEGES. This step is separate, easy to miss, and its absence produces "Error establishing a database connection" while every credential you check looks correct, because it is. The user simply has no access.
Opening phpMyAdmin
In cPanel, open phpMyAdmin. It logs you in automatically with your own credentials, and the sidebar lists the databases you can reach.
Select a database and the tables appear. WordPress tables are prefixed, usually with wp_, and the ones you are most likely to need are wp_users for accounts, wp_options for settings, and wp_posts for content.
Exporting: do this first, every time
Before any change, take an export. It takes fifteen seconds and it is the entire safety net.
Select the database, open the Export tab, keep the Quick method and SQL format, and Go. A .sql file downloads. Name it with the date and keep it somewhere other than the server.
Export the whole database rather than selected tables unless you have a specific reason. A partial export restores into an inconsistent state, and the missing piece surfaces later in a way that looks unrelated.
This is also a legitimate way to take a manual database backup, though it is only half of a site backup, files matter too. Creating and restoring backups in cPanel goes into taking both together.
Importing
Select the target database, open the Import tab, choose the file and Go.
Import into an empty database. Importing over existing tables produces either duplicate-key errors or a silent mixture of old and new rows, and the second is much worse than the first.
If the file is too large to upload, compress it: phpMyAdmin accepts gzip archives directly. If it is still too large, that is a support ticket rather than something to fight in the browser.
Resetting a WordPress password here
The most common legitimate reason to open phpMyAdmin, and worth knowing when site email is broken and password resets never arrive.
Open the wp_users table, find your row, and edit it. In the user_pass field type the new password in plain text, then select MD5 in the function dropdown beside that field.
That dropdown is the entire trick. Without it the password is stored as literal text and will never match. With it, WordPress can read the value and upgrades it to its own stronger format at your next login.
Search and replace, carefully
After moving a site or switching to HTTPS, old URLs remain stored in the database and need replacing.
Do not do this with a plain SQL UPDATE. WordPress stores some settings as serialized data, where the length of each string is recorded alongside it. A naive replacement changes the text without changing the recorded length, and the row becomes unreadable, typically breaking theme settings and widget configuration in ways that are annoying to trace back to this moment.
Use a search-and-replace tool that understands serialized data. Export first regardless.
Repairing tables
If a site reports database corruption, phpMyAdmin can repair. Select the database, select the affected tables, and choose Repair table from the actions menu.
WordPress also has its own repair mode, enabled temporarily in wp-config.php:
define( 'WP_ALLOW_REPAIR', true );
Visit /wp-admin/maint/repair.php, run it, then remove that line immediately, while the constant is set, the page is deliberately reachable without logging in.
Things not to do
Do not drop a database you cannot positively identify. Read the application's configuration file to confirm which database it uses before deleting anything. An orphaned database costs a little disk; a deleted live one costs a site.
Do not edit wp_options casually. The siteurl and home rows can lock you out of the admin area entirely if they are wrong. Setting them in wp-config.php instead is safer, because it overrides the database values and can be reverted by editing a file.
Do not run a query you do not understand because a forum post said it fixes the symptom. There is no confirmation and no undo.
Do not leave a phpinfo() file or a database export inside the site directory. A .sql file in the document root is downloadable by anyone who guesses the name, and it contains everything.
If an application cannot connect at all, the cause is usually the user instead of the database. How to Manage Database Users and Privileges deals with the step people skip.
If you would rather use a desktop tool than phpMyAdmin, do it through a tunnel rather than by opening the database to the internet. Managing MySQL and Remote Database Access in WHM walks through both routes.
