Fix MySQL Error 1114: "The Table Is Full"

You run an import, a WooCommerce report, or a heavy plugin query, and MySQL stops with ERROR 1114 (HY000): The table 'xyz' is full. WordPress might just show a blank section or "Error establishing a database connection" a minute later. The message sounds like the table hit some magic size cap. Usually it didn't. Something around it ran out of room, and finding out which "something" is the whole job.

Symptom: What You'll See

• ERROR 1114 (HY000): The table 'wp_postmeta' is full during an import or ALTER TABLE.
• The table '/tmp/#sql_1a2b_0' is full or The table '/var/tmp/#sql...' is full on a big SELECT, ORDER BY or GROUP BY.
• Inserts failing in the middle of a restore, leaving a half-loaded database.
• The PHP error log showing WordPress database error The table is full for query ....

Notice the table name in the message. It's the biggest clue you'll get, and most guides skip it.

Cause: Five Different Things Share One Error

Fix 1: Check Disk Space and Inodes First

On a VPS, start here. It's the cause far more often than any MySQL setting.

df -h
df -i
du -sh /var/lib/mysql
du -sh /tmp /var/tmp

If /var/lib/mysql's partition is at 100%, free space before you touch anything else. The usual suspects are old binary logs, giant slow-query logs and leftover dump files. We have a separate guide on MySQL binary logs filling your VPS disk that walks through safe cleanup, and another on inode exhaustion when df -h looks fine.

On shared or reseller cPanel hosting, you can't see the partition. What you can hit is your account quota. Check cPanel → Disk Usage and Databases → MySQL Databases for the size per database. If you're at your quota, MySQL writes fail with this very error. Delete old backups from /home/youruser/backup-*.tar.gz, clear unused error_log files, and retry.

Fix 2: The Temp Directory Is Full

Large sorts and GROUP BY queries spill into temporary tables on disk. If the error mentions #sql, check where MySQL puts them:

mysql -e "SHOW VARIABLES LIKE 'tmpdir'; SHOW VARIABLES LIKE 'tmp_table_size'; SHOW VARIABLES LIKE 'max_heap_table_size';"
df -h /tmp

Many VPS images mount /tmp as a small separate partition (sometimes 1–2 GB, or a tmpfs in RAM). A heavy WooCommerce analytics query can easily outgrow that. Point tmpdir at a bigger disk:

mkdir -p /var/lib/mysqltmp
chown mysql:mysql /var/lib/mysqltmp
chmod 750 /var/lib/mysqltmp

Then in /etc/my.cnf (cPanel/AlmaLinux) or /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu), under [mysqld]:

tmpdir = /var/lib/mysqltmp

Restart with systemctl restart mysqld (or mariadb / mysql, depending on your distro). On SELinux systems, a custom directory may need the right context, so check /var/log/audit/audit.log if MySQL refuses to start afterwards.

Fix 3: In-Memory Temp Tables Hitting Their Limit

MySQL builds small temporary tables in RAM. The ceiling is the smaller of tmp_table_size and max_heap_table_size. Raising only one does nothing. Set both, together:

[mysqld]
tmp_table_size      = 128M
max_heap_table_size = 128M

Don't go wild. These limits apply per temporary table, and one complex query can create several. On a 2 GB VPS, 64–128M is a sensible ceiling. Higher values just trade a clean error for an OOM kill.

Fix 4: InnoDB Data File Has a Hard Cap

Rarely, the shared tablespace was configured with a maximum size, like this:

innodb_data_file_path = ibdata1:12M:autoextend:max:512M

Once ibdata1 reaches 512M, inserts fail with "table is full" even with hundreds of gigabytes free. Check it:

mysql -e "SHOW VARIABLES LIKE 'innodb_data_file_path';"
ls -lh /var/lib/mysql/ibdata1

If there's a :max: value, remove it (keep autoextend) and restart. Also confirm innodb_file_per_table = ON, which is the default in modern versions, so each table gets its own .ibd file instead of everything piling into ibdata1.

Fix 5: Old MyISAM Tables

If the table engine is MyISAM and the table is truly huge, check:

mysql -e "SHOW TABLE STATUS FROM yourdb LIKE 'big_table'\G"

Look at Engine, Data_length and Max_data_length. If you're near the max, convert it:

ALTER TABLE big_table ENGINE=InnoDB;

Take a backup first and make sure you have free space of roughly 1.5x the table size, because the conversion builds a full copy. Ironically, running this on an already-full disk gives you... error 1114 again.

After the Fix: Check for Damage

A write that fails halfway can leave a partial import or a crashed MyISAM table. Run:

mysqlcheck -u root -p --check yourdb
mysqlcheck -u root -p --auto-repair yourdb

For a restore that died midway, drop and recreate the database, then import again from the start. Don't try to "continue" a half-loaded dump. If the site is WordPress, our guide on repairing corrupted tables covers the WP_ALLOW_REPAIR route.

Prevention

• Alert at 80% disk usage. Waiting for 100% means your database is the first thing to break.
• Rotate binary logs and slow logs (binlog_expire_logs_seconds, logrotate).
• Keep /tmp and tmpdir on a partition sized for your biggest query, not your average one.
• Before importing a large dump, check free space is at least 2x the dump's uncompressed size.
• Prune junk: expired transients, old order logs, revisions. A bloated wp_options or wp_postmeta makes every temporary table bigger.

Frequently Asked Questions

Does "table is full" mean I've reached a MySQL size limit?

Almost never on modern InnoDB. The per-table limit is in the terabytes. The error nearly always means disk, quota, temp space, or an explicit configuration cap ran out.

I'm on shared cPanel hosting. Can I fix this myself?

Often, yes. Check your disk quota and database sizes in cPanel, delete old backups and logs, and retry. You can't change tmpdir on shared hosting, so if the error mentions #sql temp tables, open a ticket with the query or plugin that triggers it.

Will raising tmp_table_size make my site faster?

Only for queries that were spilling to disk. For everything else it changes nothing, and setting it too high risks memory pressure. Raise it modestly and measure.

Is my data lost after this error?

Committed data is safe. Only the failed statement is rolled back, but a half-finished import may need to be redone. Run mysqlcheck to be sure.