MariaDB maintenance for WordPress should preserve recoverability first, then address table health, growth, slow queries, and unnecessary data. Routine destructive cleanup without evidence can break serialized options, plugin records, or recovery history.
Create and Verify a Backup
Take a consistent database backup before schema changes, repair, cleanup, or upgrades. Store it outside the hosting account, record the database version and character set, and restore it to an isolated database. Open representative pages and wp-admin after the test restore.
Check Database and Table Health
Use hosting tools or mariadb-check with an authorized account to check tables. InnoDB is the normal engine for current WordPress tables. Do not run repair commands automatically: some operations rebuild tables and require free disk space. Investigate storage or server crashes behind repeated corruption.
Review Size and Growth
List the largest tables and compare growth over time. Common sources include logs, analytics, security events, sessions, queues, revisions, and plugin caches. Identify the owning component and its retention setting before deleting rows. A table name alone does not prove data is disposable.
Control Autoloaded Options
Large autoloaded options are loaded on many requests. Measure their total and identify unusually large records, then map each to an active theme or plugin. Remove orphaned data only after a backup and owner review. Do not edit serialized values manually unless the tool preserves their structure.
Investigate Slow Queries
Use the slow query log, application monitoring, or a staging profiler during a known slow request. Record query time, frequency, examined rows, and call path. An index may help a stable query, but plugin updates can change schemas; test custom indexes and document them.
Maintain Schedules and Queues
Check WordPress cron and plugin queues for overdue or repeated jobs. A failing action that retries can grow tables and load. Fix the job before truncating its history. On busy sites, use a controlled server cron instead of relying only on visitor-triggered WP-Cron.
Plan Upgrades
Confirm WordPress, plugin, PHP, and MariaDB compatibility. Test the upgrade and rollback on staging with a production-sized database. Monitor errors, query latency, replication if used, disk space, and backups after the change.
Watch Capacity and Connections
Monitor database disk growth, free space, connection use, buffer pressure, temporary tables, and restart history. A high connection count may originate from slow PHP requests rather than a database setting. Correlate database metrics with web access and PHP worker activity before increasing limits.
Keep database credentials out of command history and shared tickets. Use a restricted maintenance account when practical, connect over a protected local or private path, and remove temporary access after the task.
After maintenance, compare page behavior, scheduled jobs, error rates, query latency, and backup size with the original baseline. Retain the evidence with the change record.
Frequently Asked Questions
Should I optimize tables every week?
No universal schedule is appropriate. Optimize when engine behavior and measured fragmentation justify the locking, I/O, and free-space cost.
Can I delete all transients?
Expired transients are generally disposable, but active applications may repopulate them and create load. Use supported WordPress tools and a backup.
Will a database-cleaner plugin make WordPress fast?
Not necessarily. Page caching, slow queries, external calls, and front-end weight often matter more. Measure before cleanup.
Maintenance Record
For every change, record backup location, restore result, query or table evidence, command, row count, duration, and validation. This turns database work from guesswork into a reversible operational process.
