Convert MyISAM to InnoDB in phpMyAdmin the Safe Way

If your error log has "Table './yourdb/wp_options' is marked as crashed" or a WooCommerce site hangs under load with lock-wait timeouts, take a look at what storage engine your tables are actually using. A surprising number of cPanel databases — especially ones that were migrated from an old host or restored from a years-old backup — are still sitting on MyISAM. Converting them to InnoDB in phpMyAdmin is a five-minute job once you know where the sharp edges are.

Why This Actually Matters

MyISAM and InnoDB aren't just two flavors of the same thing. They behave very differently under real traffic, and the difference shows up as exactly the kind of intermittent, hard-to-reproduce bugs that eat a support afternoon.

WordPress core and WooCommerce both assume InnoDB. Plugins that touch order data, sessions, or postmeta under concurrent requests will occasionally deadlock or corrupt a table if it's still MyISAM, and every WooCommerce store with real checkout traffic hits this eventually.

Symptom: How to Tell Which Tables Are Still on MyISAM

Don't guess — check. In phpMyAdmin, open your database and look at the Type column in the table list. Any table showing MyISAM instead of InnoDB is a candidate.

Faster if you have a lot of tables: run this in the phpMyAdmin SQL tab.

SELECT table_name, engine, table_rows, round(((data_length + index_length) / 1024 / 1024), 2) AS size_mb
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
AND engine = 'MyISAM';

This gives you the exact table names, row counts, and size — which matters because size determines how long the conversion takes and how much free disk space you'll need.

Cause: Why These Tables Ended Up on MyISAM

• Old dump imports. A .sql file exported from a host running MySQL 5.1 or an early cPanel default still specifies ENGINE=MyISAM in its CREATE TABLE statements, and phpMyAdmin honors that on import.
• Full-text search plugins. Some older search plugins force specific tables to MyISAM because InnoDB didn't support full-text indexes before MySQL 5.6 / MariaDB 10.0.5. That excuse is over a decade stale now, but the tables never got converted back.
• Manual table creation. If a developer created a table by hand years ago without specifying an engine, and the server's default-storage-engine was MyISAM at the time, it stuck.
• Restored backups. Restoring an old JetBackup or Softaculous backup brings the original engine with it, even if the rest of the server has moved on.

The Fix: Converting Tables in phpMyAdmin

Option 1 — One Table at a Time (Operations Tab)

1. Open phpMyAdmin from cPanel → Databases → phpMyAdmin.
2. Select your database, then click the table you want to convert.
3. Go to the Operations tab.
4. Under "Table options," find the "Storage Engine" dropdown, select InnoDB, and click Go.

This is fine for a handful of tables. For a WordPress site with 15+ tables, it's slower than just running SQL.

Option 2 — Bulk Convert via the SQL Tab

Run this per table:

ALTER TABLE wp_options ENGINE=InnoDB;

To generate the ALTER statements for every MyISAM table in one go, run the information_schema query from earlier but wrap it:

SELECT CONCAT('ALTER TABLE `', table_name, '` ENGINE=InnoDB;') AS stmt
FROM information_schema.tables
WHERE table_schema = 'your_database_name'
AND engine = 'MyISAM';

Copy the output rows, paste them back into the SQL tab, and run them as a batch. phpMyAdmin executes each ALTER in order and reports which ones failed.

What Can Go Wrong Mid-Conversion

A few things trip people up here, and they're worth checking before you run the batch, not after:

• Disk space. ALTER TABLE ... ENGINE= rebuilds the entire table as a copy before dropping the original. A 2 GB MyISAM table needs roughly 2 GB of free space mid-conversion. Check cPanel → Disk Usage first if you're anywhere near your quota.
• "Row size too large" errors. InnoDB has stricter row-size limits than MyISAM, especially with the older Antelope file format. If you hit this, switch the table's row format first: ALTER TABLE tablename ROW_FORMAT=DYNAMIC; then retry the engine change.
• Full-text index errors on old MySQL/MariaDB. If a table has a FULLTEXT index and you're on MySQL older than 5.6 or MariaDB older than 10.0.5, the conversion fails outright. Check your version in phpMyAdmin's home screen; on any current Getwebup cPanel plan this isn't an issue.
• Long lock during conversion. On a busy production site, converting a large, actively-written table (like wp_options with heavy autoload data, or WooCommerce's order tables) briefly locks it. Do this during low-traffic hours, not mid-sale.
• Foreign key mismatches. If you're converting tables that reference each other (custom app schemas, not stock WordPress), convert child tables before parent tables, or you'll get a 1215 "Cannot add foreign key constraint" error.

Always take a fresh backup before running bulk ALTERs — cPanel → Backup Wizard, or a quick mysqldump from Terminal, takes two minutes and saves you a bad afternoon if something goes sideways.

Prevention: Stop New Tables From Defaulting to MyISAM

Once everything is on InnoDB, keep it that way:

• When importing a .sql dump from an old host, open the file and search-and-replace ENGINE=MyISAM with ENGINE=InnoDB before importing, rather than converting after the fact.
• If you manage your own MySQL config (root/WHM access), confirm default-storage-engine=InnoDB is set in /etc/my.cnf — it's the default on every current cPanel/CloudLinux image, but worth a quick check after a manual MySQL upgrade.
• Run WP-CLI's built-in check periodically on WordPress sites: wp db query "SELECT table_name, engine FROM information_schema.tables WHERE table_schema=DATABASE() AND engine != 'InnoDB';" — clean output means you're fully converted.
• Avoid plugins or scripts that explicitly specify ENGINE=MyISAM in their install routine. Most well-maintained plugins moved off this years ago; if one still does it, that's a sign to look for an alternative.

If you'd rather not touch phpMyAdmin's SQL tab directly, Getwebup's hosting support can run the conversion for you as part of a routine database health check — just open a ticket with your database name and we'll handle the ALTERs and the backup.