Repair and OPTIMIZE TABLE

REPAIR TABLE and OPTIMIZE TABLE solve different problems, and they are not interchangeable. REPAIR is mainly for crashed MyISAM tables. On InnoDB, OPTIMIZE TABLE usually rebuilds the table, which can lock it or drive heavy disk use while a copy is made. Run these only when you have a clear reason, not because a plugin offered a nightly button.

Check the storage engine first

In phpMyAdmin, open the Structure tab and look at the Engine column for each table. InnoDB is the default and the right choice for WordPress. MyISAM still shows up on older sites, some plugin log tables, and leftover wp_old_* copies. If a live WordPress table is still MyISAM, convert it on a tested copy with a full dump rather than repairing it forever. MyISAM crash recovery is why REPAIR exists. InnoDB recovers through its redo log, so REPAIR on InnoDB is not the same tool.

What OPTIMIZE TABLE actually does

On InnoDB, OPTIMIZE TABLE maps to a rebuild plus ANALYZE. You get freshly clustered data and updated statistics. You also get a stretch of time while the table is copied. Running OPTIMIZE on wp_options during a busy sale is a common way to ask for free space and receive a lock instead. After you delete hundreds of thousands of rows from a log table, old postmeta, or abandoned-cart data, a deliberate one-time OPTIMIZE can return space to the filesystem. That is the case worth doing. Weekly “maintenance” is not.

ANALYZE TABLE alone is cheaper when you only need fresh stats after a bulk change. It does not rebuild the table. Use it when the optimizer behaves poorly after an import, not as a standing ritual.

Space, .ibd files, and what you will not get back

With innodb_file_per_table, each table has its own .ibd file. OPTIMIZE can shrink that file after a large delete. The shared system tablespace does not shrink when you remove rows, which still surprises people. Check the engine and the on-disk size, then decide whether a rebuild is worth it. Remote MySQL does not change any of this behavior; it only adds latency to the rebuild. See remote MySQL: when not to if the next idea is to run OPTIMIZE from a laptop across the internet.

Reclaim space after a huge delete on purpose, and try it on staging first. Do not OPTIMIZE every table every night because a plugin made the button easy to click.