MySQL Error 1034 (ER_NOT_KEYFILE) indicates that MySQL cannot read the index (key) file for a table, usually due to corruption caused by disk issues, crash interruption, or filesystem problems. Common causes include insufficient disk space, permission errors, and MyISAM table corruption. Fixing requires checking disk space, repairing tables, and verifying filesystem health.
MySQL Error 1034 indicates that MySQL cannot access or read the physical index (key) file for a table. For MyISAM tables, this refers to the .MYI (MySQL Index) file; for on-disk temporary tables created during joins or large result sets, it refers to temporary key files in tmpdir. The error occurs when the key file is corrupted, inaccessible, or missing entirely. Unlike other corruption errors tied to specific operations, Error 1034 can surface during any table scan or index lookup. The message "Incorrect key file for table; try to repair" is MySQL's way of saying the index structure is unreadable. This error is most common with MyISAM tables (older default engine) but can occur with InnoDB when creating temporary on-disk tables for large sorts or joins. Regardless of the storage engine, the underlying cause is almost always one of: insufficient disk space preventing proper file creation, file system corruption from a crash or power loss, permission issues on the table files, or filesystem becoming read-only after detecting errors.
The error log provides the table name and context for the error. This tells you which table to focus on.
# On Linux/Unix:
tail -100 /var/log/mysql/error.log
# On Windows:
type "C:\ProgramData\MySQL\MySQL Server 8.0\error.log"
# Or query the current log file location:
SHOW VARIABLES LIKE 'log_error';Look for messages like "InnoDB: Corrupted index page was detected in table" or "MyISAM: Found key at offset X that points into the deleted link". Note the table name for the next steps.
Error 1034 is frequently caused by disk exhaustion preventing proper file creation or updates.
# Check overall filesystem usage:
df -h
# Check specific MySQL data directory:
du -sh /var/lib/mysql
# Check space on that partition:
df -h /var/lib/mysql
# Check tmpdir space:
df -h /tmp
# Or see configured tmpdir in MySQL:
SHOW VARIABLES LIKE 'tmpdir';If available space is less than 10% of partition size or shows 100% used, free up disk space immediately. Remove old binary logs, backups, or other large files.
After a crash or disk error, the filesystem may mount as read-only, preventing any writes.
# Check mount status:
mount | grep -E "mysql|var|data"
# Look for "ro" in the output. If present, remount as read-write:
sudo mount -o remount,rw /var/lib/mysql
# Verify the remount succeeded:
mount | grep /var/lib/mysql
# Test write access:
sudo touch /var/lib/mysql/.write_test && sudo rm /var/lib/mysql/.write_testIf remounting fails, the filesystem has detected corruption and requires fsck (offline, expert supervision).
The mysql OS user must have write permissions on the datadir and table files.
# Check directory permissions:
ls -ld /var/lib/mysql
ls -l /var/lib/mysql/database_name/
# The mysql user should own these directories:
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql
# Verify:
ls -ld /var/lib/mysqlMissing write permissions prevent MySQL from writing to the .MYI file.
REPAIR TABLE rebuilds the corrupted index file. Always back up before attempting repair.
# First, flush and lock the table:
FLUSH TABLES table_name FOR EXPORT;
# Repair the table:
REPAIR TABLE table_name;
# Or for quick repair (safer):
REPAIR TABLE table_name QUICK;
# Or for extended repair (slower, more thorough):
REPAIR TABLE table_name EXTENDED;
# Check table status:
CHECK TABLE table_name;If REPAIR TABLE fails, proceed to myisamchk.
If REPAIR TABLE fails, use myisamchk offline. This requires stopping MySQL.
# Stop MySQL:
sudo systemctl stop mysql
# Try quick repair first (fastest):
myisamchk -r -q /var/lib/mysql/database_name/table_name.MYI
# If quick repair fails, try standard repair:
myisamchk -r /var/lib/mysql/database_name/table_name.MYI
# If that fails, try safe recovery (slowest):
myisamchk --safe-recover /var/lib/mysql/database_name/table_name.MYI
# Start MySQL:
sudo systemctl start mysql
# Verify the table:
CHECK TABLE table_name;Quick repair (-q) only rebuilds the index without touching the data file. Standard repair removes incorrect rows. Safe recovery is for severe corruption.
InnoDB handles repair differently. Use ALTER TABLE to rebuild the table structure.
# Rebuild the table (may take time for large tables):
ALTER TABLE table_name FORCE;
# Or:
ALTER TABLE table_name ENGINE=InnoDB;
# Verify:
CHECK TABLE table_name;For severe InnoDB corruption, you may need to dump the table data and recreate it.
Severe index corruption may be unrecoverable. If repair fails, restore the table from a backup.
# Check if a backup exists:
ls -lh /path/to/backups/
# If using mysqldump backup:
mysqldump -u root -p database_name < /path/to/backup.sql
# Or if using Percona XtraBackup:
xtrabackup --prepare --target-dir=/mnt/backup
xtrabackup --copy-back --target-dir=/mnt/backupIf no backup exists, the table data may be unrecoverable. As a last resort, drop the table and recreate it with empty structure.
After repair, restart MySQL cleanly and monitor logs for any recurrence.
# Restart MySQL:
sudo systemctl restart mysql
# Verify it started:
sudo systemctl status mysql
# Test with a simple query:
mysql -u root -p -e "SELECT COUNT(*) FROM table_name;"
# Monitor error log:
tail -f /var/log/mysql/error.log
# Set up monitoring for disk space and table statusIf Error 1034 recurs shortly, the underlying disk or filesystem issue persists and needs deeper investigation.
For temporary table errors, the corruption usually occurs in tmpdir, not in the permanent data directory. Large queries that create on-disk temporary tables during sorting or joining will fail with Incorrect key file if tmpdir is full or has permission issues. Increase tmp_table_size and max_heap_table_size to prefer in-memory temporary tables, and ensure tmpdir is on a partition with ample free space.
MyISAM corruption spreads across .MYI (index), .MYD (data), and .frm (structure) files. If .MYI is corrupted but .MYD is intact, recovery usually succeeds. However, if both are damaged, REPAIR TABLE with USE_FRM option forces table recreation from the .frm file, discarding any unrecoverable data: REPAIR TABLE table_name USE_FRM.
In replication environments, a crashed replica table stops replication until repaired. After repair, verify replication status with SHOW SLAVE STATUS and resume if needed. The master will have advanced ahead, so consider using CHANGE MASTER TO and resync if the lag is significant.
On high-concurrency systems, consider converting MyISAM tables to InnoDB. InnoDB has better crash recovery, supports transactions, and is less prone to this type of corruption.
For containerized MySQL (Docker, Kubernetes), ensure the container storage or mounted volume has adequate inode and space limits. Use docker inspect or kubectl describe to monitor resource usage. In Kubernetes, Persistent Volume Claims should have sufficient space allocated.
EE_WRITE (3): Error writing file
How to fix "EE_WRITE (3): Error writing file" in MySQL
CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters
How to fix "CR_PARAMS_NOT_BOUND (2031): No data supplied for parameters" in MySQL
CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed
How to fix "CR_DNS_SRV_LOOKUP_FAILED (2070): DNS SRV lookup failed" in MySQL
ERROR 1146: Table 'database.table' doesn't exist
How to fix "ERROR 1146: Table doesn't exist" in MySQL
ERROR 1040: Too many connections
How to fix "ERROR 1040: Too many connections" in MySQL