Stop ‘Repairing’ Databases You Haven’t Diagnosed

A database warning appears. Someone searches the error. A forum
answer suggests a maintenance command. Five minutes later, production is
running REPAIR TABLE, OPTIMIZE TABLE or an
ALTER statement without a clear model of the problem.

Sometimes that works.

Sometimes it makes the original evidence harder to interpret.

The better default is simple:

Observe structure first. Mutate second.

“Database issue” is not a
diagnosis

That phrase can describe completely different failure modes:

• connection failure;
• exhausted storage;
• schema drift;
• missing index;
• table corruption;
• incompatible charset;
• lock contention;
• slow query;
• unexpected table engine;
• data growth;
• permission failure.

A single repair command cannot correctly address all of them.

Start with server and schema
facts

Before changing anything, capture basic metadata.

Useful MySQL/MariaDB observations include:

SELECT VERSION();
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW TABLE STATUS;

For a specific table:

SHOW CREATE TABLE some_table;
SHOW INDEX FROM some_table;

These queries let you inspect engine, collation, indexes and the
actual schema the server is using.

They are evidence gathering.

Engine matters

Modern WordPress and XenForo deployments commonly rely on InnoDB
behavior.

If one unexpected table is using another engine, the important
question is why.

Possible explanations include:

• a legacy migration;
• a third-party plugin/add-on;
• a manual import;
• old hosting defaults.

Do not automatically convert it merely because it is different.

First identify ownership and compatibility requirements.

Charset and collation drift

Mixed character sets can remain invisible until a specific input
arrives or a comparison crosses tables.

A health review should identify inconsistent tables or columns,
especially around utf8mb4 expectations.

But changing charset can be expensive and potentially destructive if
done without backups, disk headroom and an understanding of index
limits.

Detection belongs in the diagnostic phase. Conversion belongs in a
planned maintenance phase.

Missing
indexes and duplicate indexes are different problems

Indexes affect performance and storage.

A missing expected index may make a query progressively slower as
data grows.

A redundant index may waste storage and write work.

Neither observation justifies blindly running an optimization
command.

Inspect the real index definitions:

SHOW INDEX FROM some_table;

Then compare them with what the application version expects.

For application-owned tables, migration/install definitions are the
best reference when available.

Primary keys are
operationally important

Tables without an appropriate primary key can behave poorly under
replication, row identification and some maintenance patterns.

A diagnostic can flag the absence of a primary key as an unusual
condition.

But not every table design is identical. A reporting or staging table
may intentionally differ.

Again: flag, explain, attribute ownership.

Capacity signals are
cheap and useful

Table metadata can reveal growth without expensive
COUNT(*) scans.

For example, table status can provide approximate rows, data length
and index length.

This helps answer:

• Which tables dominate storage?
• Did one table grow unexpectedly?
• Is a log table retaining too much history?
• Is the database approaching a hosting limit?

Growth is often the earliest warning before performance or backup
times become painful.

Auto-increment
capacity deserves attention before it becomes urgent

An auto-increment value can approach the maximum of its integer
type.

This is uncommon on small sites but important on long-running
high-volume tables.

A read-only check can compare the current value with the column
type’s capacity and report headroom.

That is exactly the kind of issue you want to discover while the site
is still healthy.

What
REPAIR TABLE is actually for

REPAIR TABLE is not a universal “make database healthy”
command.

Its applicability depends on storage engine and failure mode. InnoDB
recovery is a different topic from repairing certain MyISAM-style
tables.

Running a command that is irrelevant to the engine adds noise and can
mislead the administrator into believing something meaningful was
fixed.

OPTIMIZE TABLE
is not a magic speed button

Optimization may rebuild or reorganize storage depending on the
engine and server version.

That can consume time, I/O and temporary disk space.

It can also be unnecessary.

Before scheduling it, identify the actual operational problem:

• Is storage fragmentation material?
• Is reclaiming disk space necessary?
• Is query performance the issue?
• Is the expected benefit worth the maintenance cost?

If you cannot answer those questions, “optimize” is not yet the right
action.

Schema drift after upgrades

One especially useful database check is comparing expected
application structure with observed structure.

An interrupted upgrade can leave:

• missing columns;
• stale columns;
• missing indexes;
• partially created tables.

The safest repair is normally the application’s supported
migration/upgrade path, not hand-written SQL copied from another
installation.

Manual SQL should be a deliberate recovery action after identifying
exactly which migration failed.

Backups before mutation

Read-only inspection is low-risk.

Schema changes are not.

Before any repair, conversion or alter operation:

1. verify a recent backup exists;
2. verify the backup is readable;
3. understand rollback;
4. estimate table size and available disk;
5. plan lock/runtime impact;
6. perform the supported application maintenance procedure where
   possible.

A backup that has never been checked is not strong evidence of
recoverability.

A safer diagnostic sequence

When a database concern appears:

Step 1 — Define the symptom

Is it an error, slow request, missing table, encoding problem or
capacity warning?

Step 2 — Capture read-only
evidence

Version, engine, collation, schema, indexes, sizes and relevant
logs.

Step 3 — Identify ownership

Core table, plugin/add-on table or custom table?

Step 4 — Compare with
expected state

Use the correct application/version schema reference.

Step 5 — Choose the
smallest justified change

Only after the failure mode is understood.

Diagnostics
should be comfortable doing nothing

A good database health tool can report:

Table uses unexpected engine
Owner: third-party add-on
Current state: readable
Automatic repair: not attempted

That is useful.

It preserves evidence and avoids turning a diagnostic plugin into a
database mutation engine.

There is a time for ALTER, OPTIMIZE and
recovery operations.

The first minute after seeing a warning is usually not that time.