iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A safe WordPress database cleanup is a controlled maintenance job: make a restorable backup of the database and files, identify the actual table prefix, inspect what is consuming space, remove only data with a known owner and retention rule, optimize during a quiet period, and test the site afterward. There is no universal cleanup interval or guaranteed speed gain. The right schedule follows your site’s writing activity, table growth, autoloaded options, query behavior, backup results, and error logs.
What database cleaning should accomplish
WordPress stores content, settings, comments, metadata, scheduled information, and plugin data in MySQL or MariaDB tables. Over time, revisions, auto-drafts, trashed comments, expired cache records, and data left by removed extensions can accumulate. Cleaning means deciding which records are disposable, deleting them in a reversible way, and leaving the application’s required data intact. It is not the same as blindly emptying large tables or running an optimization command on a schedule.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →
A successful maintenance pass should leave you with a documented backup, an inventory of the tables and their owners, a record of what was removed, and evidence that publishing, forms, search, scheduled jobs, and important front-end paths still work. Optimization can reclaim space or reorganize tables, but it cannot correct a plugin that continually writes unwanted rows, repair broken application logic, or substitute for query profiling.
1. Create a complete, restorable backup first
Do not delete a row until you have a current export of every database table. Keep that export with a backup of the site files so the database and files remain one recovery set. The file portion should include wp-content, themes, uploads, WordPress core files, and configuration such as wp-config.php. WordPress documents exporting through phpMyAdmin and using mysqldump; exports can be compressed as .gz or .bz2.
#1 Best Overall
- 110 Sheets Log Book: This vehicle maintenance log book includes 110 record sheets to track repairs, services, fuel costs, and other vehicle-related expenses. It also comes with 36 convenient “Service Due” stickers to help remind you of upcoming maintenance schedules. Everything you need to keep your car records organized in one place.
- Detailed Information: Each page is carefully structured with dedicated sections for date, mileage, service description, parts replaced, vehicle information, cost, and additional notes. The clear and organized format allows you to maintain accurate records, monitor repair history, and better manage long-term vehicle performance and expenses.
- Enough Writing Space: The record sheets provide ample space for clear and thorough entries. Whether you’re documenting routine oil changes or major repairs, there’s plenty of room to write detailed information without feeling cramped.
- Easy to Use: The spiral binding allows the notebook to lay flat for comfortable writing, making entries quick and convenient. The included 36 “Service Due” stickers can be placed inside the book or on visible surfaces like your windshield or dashboard, helping you keep important maintenance reminders in sight.
- Proper Size: This compact logbook measures 5.5” x 7.1”, which fits easily in your glove compartment, center console, backpack, or desk drawer. Its portable size ensures you can access and update your vehicle records anytime, whether at home, in the garage, or at the service center.
- Choose a low-write period and stop imports, queue workers, and scheduled bulk operations that could change rows while you compare the before and after state.
- In phpMyAdmin, select the site database, choose an export that includes all tables and structure, and save the dump outside the live server. Alternatively, use the WP-CLI export command shown later.
- Copy the site files into the same backup set. A database-only dump cannot restore uploaded media, themes, plugins, or configuration.
- Keep at least one copy away from the hosting account, with restricted access. A backup that has never been tested is only an assumption, so restore a copy to staging when your hosting process allows it.
- Record the WordPress, PHP, MySQL or MariaDB, theme, and plugin versions. The record makes a later rollback or comparison less ambiguous.
Retain the pre-cleanup export until the site has operated normally through a representative period. Do not overwrite it immediately with the post-cleanup backup.
2. Work on staging whenever possible
Destructive cleanup is safest on a clone or hosting snapshot. A staging copy lets you measure table sizes, run deletion queries, clear caches, and test application behavior without exposing visitors to a partially changed database. If staging is unavailable, take the snapshot and export immediately before the live operation, schedule a maintenance window, and keep the change set small enough to reverse.
Pause high-write activity such as product imports, membership synchronization, form-processing queues, analytics ingestion, and scheduled bulk updates. Note the versions of WordPress, PHP, MySQL or MariaDB, the active theme, and every active plugin. A table that appears unused on one version may be required after an update or migration.
3. Find the real table prefix
Never assume that tables begin with wp_. WordPress reads the prefix from the $table_prefix setting in wp-config.php. A site may use a custom prefix, and multisite installations have additional site-specific tables. Installations sharing one database can contain several prefixes.
- Open the correct
wp-config.phpfor the site you are maintaining. - Read the value assigned to
$table_prefix. - Match that value against the tables shown in phpMyAdmin or WP-CLI.
- Separate this site’s tables from tables belonging to another installation before exporting, deleting, or optimizing anything.
Using an assumed prefix can make a query affect the wrong site or make you overlook the tables you intended to inspect.
4. Inventory tables before deciding what to remove
Start with a list of names, approximate sizes, row counts, and apparent owners. In WP-CLI, these commands provide a repeatable inventory:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
wp db check
wp db tables
wp db size
wp db columnsphpMyAdmin provides the same information through its database and table views. Export the inventory or record it in the maintenance log. Large size alone is not proof that a table is disposable: an ecommerce catalog, membership records, order history, or a custom post type may legitimately contain millions of rows.
| Area | What to inspect | Safe decision rule |
|---|---|---|
*_options |
Option names, value sizes, and autoload flags | Keep settings owned by active code; remove only records whose owner and purpose are confirmed |
*_posts |
Revisions, auto-drafts, trash, and custom post types | Apply the site’s retention policy and verify that no workflow depends on historical versions |
*_postmeta |
Metadata whose referenced post no longer exists | Confirm that no active plugin, migration, or custom type uses it before removal |
*_comments and *_commentmeta |
Spam, trash, and associated metadata | Use WordPress moderation tools and preserve legally or operationally required records |
| Plugin-specific tables | Table names, row growth, and the extension that created them | Remove leftovers only after checking uninstall behavior and site requirements |
5. Clean the common growth areas carefully
wp_options and autoloaded settings
The options table contains core settings and data belonging to themes and plugins. Inspect the largest values and the autoload flag, but do not delete an option merely because its name is unfamiliar. An active extension may use a name that is not obvious from the front end, and a custom integration may depend on a value that appears only in scheduled jobs.
Rank #2
- All In One Equipment Maintenance Log Book With Detailed Fields：This equipment maintenance log book is designed for complete tracking of machinery and equipment performance Featuring pre-printed sections for Equipment Name Manufacturer Name Model Number Serial Number Purchase Date Item Location and Additional Information this repair log book ensures accurate and consistent service records
- Includes Maintenance Schedule Fields for Time and Task Recording：Each page includes dedicated spaces for Date and Time Maintenance Task or Remarks Performed By and Cost helping you record maintenance frequency track service intervals and monitor expenses Ideal for preventive maintenance logs and repair history documentation
- Large Format Repair Log Book With Continuation Pages：Sized at 8.5 x 11 inches this equipment service record notebook provides generous space for writing and includes 110 Pages with continuation pages to extend entries when needed Ensures that even complex service reports are kept complete and organized
- Durable Spiral Bound Construction for Long Term Use：Built with a 300gsm laminated cover and strong spiral binding this maintenance log notebook lies flat for easy writing and endures frequent handling in demanding environments from factory floors to fieldwork sites
- Ideal for Industrial Commercial and Personal Equipment Tracking：Whether you’re managing heavy machinery in construction agricultural tools in farming or facility systems in schools or warehouses this maintenance record book helps technicians engineers and facility managers maintain consistent and accessible logs
Large autoloaded values are loaded on ordinary WordPress requests, so they deserve investigation. Identify the owning extension, confirm that it is active or that the setting is intentionally retained, and use that extension’s documented cleanup or uninstall routine when available. Deleting an option directly can reset settings, break a login flow, or remove a license or integration configuration.
Transients and cached values
The Transients API provides temporary cached data. Without persistent object caching, transients are commonly stored in *_options. Expiring transients are not autoloaded by default, while transients created without an expiration are autoloaded. A persistent object-cache system can store transient data outside the database, so an empty options table does not prove that no transients exist.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Review transient names and expiration state, and remove only expired or clearly disposable entries. A transient is cache, not authoritative content; WordPress or the owning plugin should be able to regenerate it. Do not treat every option beginning with a transient-like prefix as safe if a plugin uses it for a state flag or lock.
Revisions, auto-drafts, and trash in wp_posts
Post revisions are historical copies. Decide how many revisions the editorial process actually needs, then remove older revisions through a trusted WordPress-aware tool or a carefully reviewed operation. Keep revisions when editors rely on them for compliance, approvals, or recovery. Auto-drafts are abandoned editor placeholders; confirm that no collaborative workflow is using them before deletion. Trashed posts should follow the site’s retention rule rather than an arbitrary age.
Spam and trashed comments
Use the WordPress Comments screens to moderate spam and empty the trash. Check retention, legal-hold, customer-service, and moderation requirements first. Comment metadata can remain after a comment is removed, so inspect associated records only after confirming that the references are genuinely orphaned.
Orphaned post metadata
Rows in *_postmeta are orphaned when their referenced post no longer exists, but an apparently unreferenced key is not automatically junk. Custom post types, migrations, multilingual systems, and active plugins can use metadata in ways that are not visible in the standard editor. Identify the key’s owner, check active code and scheduled jobs, and take an export before removing confirmed orphans.
Recommended Free Tools
Tables left by removed plugins
Record which plugin created each non-core table. Check the plugin’s uninstall documentation and whether the site may be reactivated, migrated, or queried by another service. Some uninstall routines intentionally preserve settings or data; others offer a setting to remove everything. Remove a custom table only when its ownership, retention requirement, and backup status are known.
6. Use WP-CLI for repeatable, reviewable work
WP-CLI is useful when maintenance must be repeated across staging and production or recorded in a change log. Run commands as the site’s correct system user and from the WordPress installation directory.
wp db check
wp db tables
wp db size
wp db columns
wp db export /secure/path/site.sql
wp db optimizewp db check checks database health before and after the change. The inventory commands list tables, sizes, and columns. wp db export creates a SQL dump that you can move to protected storage. Run wp db optimize only after confirmed disposable data has been removed and during a low-traffic window.
WP-CLI also exposes wp db clean, wp db drop, and wp db reset. These can remove tables or the entire database; treat them as destructive, exceptional commands, not housekeeping shortcuts. Do not run them on a production site without a verified restore path and an explicit change plan.
7. Choose the right maintenance tool
There is no single best interface. Use the tool that gives you the clearest ownership information, rollback path, and audit trail for the task.
| Tool | Best use | Strengths | Risks or limits |
|---|---|---|---|
| WP-CLI | Repeatable checks, exports, optimization, and scripted maintenance | Documentable commands, easy staging-to-production comparison, useful size and column inventory | A mistaken command can be destructive; shell access and correct site context are required |
| phpMyAdmin | Visual inspection, exports, targeted table actions, and emergency repair | Shows rows, structures, sizes, and table controls without shell access | Manual deletion is easy to misapply; large operations can time out or lock tables |
| Database-cleanup plugin | Guided review, scheduling, and WordPress-aware cleanup | Convenient interface and, depending on the plugin, previews or scheduled tasks | Detection of orphaned options and custom tables is imperfect; deletion lists still need human validation |
WordPress housekeeping documentation lists WP-Sweep as one database-optimization option. The official WP-Optimize listing describes cleanup features and requires a full database backup before first use or a major upgrade. A plugin can simplify review, but it cannot know every custom table owner or business retention rule. Review its proposed deletions, export first, and test on staging when possible.
8. Optimize only after cleanup
Optimization reorganizes table storage after confirmed rows have been removed. Check the storage engine and your host’s guidance first, because the operation can consume temporary disk space, hold locks, or take a long time on a busy table. Schedule it during a quiet period and monitor the database server.
Run wp db optimize or the equivalent table action in phpMyAdmin after the deletion review. Optimization does not replace indexes designed for the actual query workload, profiling of slow queries, or correction of a plugin that keeps generating unwanted data. It also does not guarantee a measurable front-end speed increase; the result depends on table structure, cache layers, traffic, and the work performed by the application.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute9. Repair a table only when there is evidence of damage
Repair is for a crashed or corrupt table, not for routine cleanup. If MySQL or MariaDB reports an error, first take a fresh backup of the current database state and note the exact message.
Repair through phpMyAdmin
- Open the site’s database in phpMyAdmin and verify the table prefix.
- Select the affected table or tables.
- Choose the Repair Table action.
- Review the result and inspect the server or WordPress error log if the repair fails.
- Run
wp db checkand test the site before resuming queued jobs.
Use the emergency WordPress repair page
WordPress documents an emergency repair mechanism controlled by WP_ALLOW_REPAIR. Add the setting to wp-config.php only when needed:
define('WP_ALLOW_REPAIR', true);Then visit /wp-admin/maint/repair.php for the affected installation. The page may be reachable without a normal WordPress login, so an unauthorized person who discovers it could run repair actions. Remove the setting immediately after the operation and test again. Do not leave it enabled as a standing maintenance feature.
10. Verify the site after every destructive change
Clear the WordPress page cache, object cache, and any configured edge cache after the database operation. Then test the paths that matter to the site rather than relying on a successful database command.
- Open the homepage, representative posts, pages, categories, and search results.
- Log in as an administrator and, if applicable, as a normal member or customer.
- Edit, save, schedule, and publish a test item; confirm that revisions behave as expected.
- Upload and display media.
- Submit forms and confirm that notifications or integrations arrive.
- Moderate a comment and check spam and trash behavior.
- Run an ecommerce checkout or membership renewal in a safe test mode when the site supports it.
- Inspect scheduled events, queue workers, REST or API integrations, and webhooks.
- Review PHP, WordPress, web-server, and database error logs for new warnings.
Keep the before-cleanup export and the maintenance log until these checks pass through normal traffic and scheduled activity. If a setting disappears, a plugin fails to initialize, or a page begins returning errors, stop further cleanup and restore the matching database-and-files backup rather than guessing which rows to recreate.
How to investigate common failures
A cleanup plugin proposes hundreds of unfamiliar options
Do not bulk-delete the list. Group options by owner, compare them with active and previously installed plugins, inspect value size and autoload state, and remove only entries confirmed to be abandoned. Ask the plugin author or inspect uninstall documentation when ownership is uncertain.
A large deletion times out
Restore or verify the backup, then work in smaller batches on staging. Use a low-traffic window, pause high-write jobs, and watch locks and disk space. A timeout does not tell you whether some rows were already removed, so compare counts before repeating the command.
The database is healthy but pages remain slow
Cleaning rows is not a substitute for finding the slow query, expensive plugin hook, remote API call, PHP bottleneck, or cache miss. Use query and application profiling, inspect autoloaded data, and address the component producing the workload.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteA plugin was removed but its tables remain
Confirm that no active code, scheduled task, reporting process, or future migration reads those tables. Export them, document the decision, and remove them only when the retention requirement and uninstall behavior are clear.
When should you repeat database maintenance?
Official WordPress guidance does not establish a universal weekly, monthly, or quarterly interval, nor a guaranteed percentage improvement from deleting rows. Instead, monitor table growth, autoloaded data, query performance, backup completion and restore tests, and error logs. Review after a high-volume import, a major migration, removal of a plugin that stores substantial data, or a change in publishing or commerce volume. A low-write brochure site may need infrequent review; a busy store or membership site may need a documented check more often.
Set a reminder based on observed growth and risk, not an arbitrary promise. Each review should produce the same evidence: a complete backup, an inventory, the exact records or tables considered, the commands or UI actions used, the test results, and the location of the rollback copy.
Quick Recap
A practical decision checklist
- Back up: database and WordPress files are together, the dump is off-server, and a restore path is known.
- Identify: the real
$table_prefix, site type, database engine, and active extensions. - Inspect: sizes, row counts, autoloaded options, transient state, revisions, auto-drafts, trash, comments, metadata, and custom tables.
- Validate ownership: every proposed deletion has a known owner, retention rule, and regeneration or restore path.
- Change cautiously: use staging or a maintenance window, record commands, and avoid destructive WP-CLI reset commands.
- Optimize: run table optimization only after cleanup and only when host conditions permit it.
- Verify: clear caches, test critical workflows, inspect logs, and retain rollback evidence.
