RVS Database Doctor
RVS Database Doctor is a professional database administration tool. It gives you insight into the current state, safely cleans and optimizes, and shows exactly how much you saved – with full support for large databases. Key features Dashboard with health score and one-click Optimize Now. Time-based job runner (default batch 1000, auto-adapts to max_execution_time) – works smoothly on databases with 100k+ rows. Background queue (WP-Cron drain every minute, Action Scheduler when available) – you can close the tab and the job continues. Before / After snapshots with SVG charts and per-table delta (no external dependencies). Guided Safe Cleanup Wizard with recommended selections, CARE confirmations, before/after snapshots, and cleanup result deltas. Smart Advisor v2 – health score (0-100, grade A-F), actionable tips, and EXPLAIN query-plan hints for slow queries. Bulk actions for Table Sizes, Autoload Options, Index Analysis, and Cleanup tabs. Manual full database backup with a user-selectable table list and manifest.json metadata. Choose PHP chunked dump (works anywhere) or native mysqldump (fast). Full database restore from plugin-created backups – automatic pre-restore backup, streaming SQL import, progress tracking, and mandatory confirmation (type RESTORE). Micro-backup of affected tables before destructive operations (gzip when available, retention by days and count). Scheduled optimizations – hourly / daily / weekly / monthly. Scheduled health digest emails – daily, weekly, or monthly summaries sent to the configured notification email. MyISAM → InnoDB conversion (batched with progress bar). Autoload analysis with severity levels, segmentation, search, filter, pagination, and bulk update – no longer limited to 50 options. Index analysis – missing expected, composite suggestions, sys redundant / unused. WooCommerce / HPOS detection and specific suggestions. Cleanup: expired transients, revisions, auto-drafts, old trash, spam / trash comments, orphan postmeta / commentmeta / term_relationships, expired WC sessions, Action Scheduler old actions / logs, duplicate postmeta, stale session tokens, _edit_lock / _edit_last. Actions log – every attempt is recorded (success / error / dry-run). WP-CLI commands for every action including backup create --all, backup validate , and backup restore --confirm=RESTORE (wp rvs-database-doctor …; wp rvs-db-doctor … is also supported). Safety rules All destructive actions require the manage_options capability + nonce + explicit confirmation checkbox. Table names are validated against information_schema before any ALTER / ANALYZE / OPTIMIZE / DELETE. Auto-backup of affected tables before destructive operations (enabled by default). The plugin never deletes anything automatically; Optimize Now runs safe categories only by default.
WP-DBManager
WP-DBManager looks after the database behind your site: it backs it up, restores it, optimizes and repairs it, empties or drops tables and runs queries you write, all from wp-admin rather than from a shell or phpMyAdmin. Backups, optimization and repair can be left to run on a schedule, and the backup can be emailed to you when it finishes. Donations I spent most of my free time creating, updating, maintaining and supporting these plugins, if you really love my plugins and could spare me a couple of bucks, I will really appreciate it. If not feel free to use it without any obligations. Usage Securing The Backup Folder A database backup contains everything, including your users table. Anyone who can guess a backup file name can download the lot, so the folder must not be served over HTTP. The reliable option, on any server: set Path To Backup under WP-Admin -> Database -> Settings to a folder outside your web root, for example /var/www/example.com/backup-db when WordPress lives in /var/www/example.com/public_html. Nothing served, nothing to configure. If the folder has to stay inside the web root: Apache — move htaccess.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/.htaccess IIS — move Web.config.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/Web.config nginx — nginx does not read .htaccess files, so the file above does nothing. Add this to your server block and reload nginx: location ^~ /wp-content/backup-db/ { deny all; } Move index.php from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/index.php as well, so the folder cannot be listed. The Backup DB page requests a file from the folder and reports what the server actually returns, so you can confirm the folder is closed rather than assume it. WP-CLI wp dbmanager tables wp dbmanager backups wp dbmanager backup --yes wp dbmanager backup --no-gzip --yes wp dbmanager restore --yes wp dbmanager delete ... --yes wp dbmanager email --to=ops@example.org --yes wp dbmanager optimize --all --yes wp dbmanager repair wp_options --yes wp dbmanager empty ... --yes wp dbmanager drop ... --yes Everything that changes anything asks first, so a script has to pass --yes. That includes backup, which deletes the oldest backups to stay inside Maximum Backup Files, and email, because a dump holds your users table and a sent message cannot be recalled. tables and backups only read, and take a --format of table, csv, json, yaml, count or ids; their sizes are in bytes rather than the KiB and MiB the screens print, because a shell is better at arithmetic than at parsing 1.2 MiB. optimize and `repair` take table names or `--all`. `empty` and `drop` take names only: emptying or dropping every table in a database is not maintenance, and the screen at least shows you the list before you tick it. There is no run subcommand. WP-CLI already ships wp db query, which reaches the same database through the same client, so the Run SQL Query screen has no command counterpart. That screen is unchanged and still works. wp dbmanager checks no capability. WP-CLI has no logged-in user unless you ask for one with `--user`, and whoever can run it can already read the credentials in `wp-config.php`, so a check would refuse every scheduled backup script while protecting nothing. The `install_plugins` gate on the admin screens is unchanged.
