MySQL error 1034 means the server cannot use a table’s key file (its index data) consistently. The usual case is a damaged MyISAM index. Identify the table engine first, make a backup, then run CHECK TABLE and, for MyISAM, repair it with REPAIR TABLE. If the server is stopped, the offline myisamchk utility provides a second repair path. Do not apply these MyISAM commands to an InnoDB table.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The message is usually shown as Incorrect key file for table 'table_name'; try to repair it. It is error 1034 (symbol ER_NOT_KEYFILE, SQLSTATE HY000). A repair can discard unrecoverable rows or index entries, so preserve a backup before changing table files.
As an Amazon Associate I earn from qualifying purchases.
What error 1034 means
A MySQL table can have a data file and one or more index (key) structures. Error 1034 is raised when MySQL finds that a key file is missing, damaged, inconsistent with the data file, or otherwise unusable. The server’s own wording is: “Incorrect key file for table ‘%s’; try to repair it.”
In practice, this message most often concerns a MyISAM table whose index has been corrupted. The table may also be reported as crashed, not closed properly, or corrupted. The message does not, by itself, tell you whether the data rows are intact or which repair method is safe; those decisions depend on the storage engine and whether the server is online.
#1 Best Overall
Common causes
Oracle MySQL documents several ways MyISAM corruption can occur:
- mysqld was killed during a write. A forced process termination can leave data and index updates only partly written.
- An unexpected shutdown. Power loss, a kernel panic, or an unclean service stop can prevent normal table closure.
- Hardware or storage failure. Bad sectors, controller problems, or filesystem errors can damage table files.
- An external program changed table files while mysqld was using them. Copying, replacing, or editing the files behind the server’s back can invalidate indexes.
- A MySQL or MyISAM software bug. A reproducible defect can produce the same symptom even when the operating system is healthy.
Do not assume that a one-time repair fixes the underlying cause. If corruption returns, investigate shutdown history, storage health, concurrent file access, and the MySQL error log.
First identify the table engine
Run these statements in the affected database, replacing the name with the exact table:
SHOW TABLE STATUS LIKE 'table_name';
SHOW CREATE TABLE table_name;The first statement displays an Engine column. The second shows the complete table definition, including the ENGINE= clause. Confirm the name and database before repairing; a similarly named table in another schema is a common operational mistake.
| Engine reported | What the standard repair instructions mean | Immediate action |
|---|---|---|
| MyISAM | CHECK TABLE, REPAIR TABLE, and myisamchk are the relevant tools. |
Back up the table, check it, then choose online SQL repair or offline utility repair. |
| InnoDB | MyISAM key-file procedures are not a general InnoDB repair method. | Use an InnoDB-specific recovery plan and version-appropriate documentation; do not run myisamchk on it. |
| Another engine | The commands and failure modes differ by engine. | Consult that engine’s consistency and recovery procedure. |
Back up before any repair
Repair tools can remove damaged index entries and may lose rows that cannot be reconstructed. Preserve a copy before running a command that changes data or table files.
- If the server still answers queries, take a logical backup of the affected database or table using your normal backup process and verify that the dump can be read.
- For a physical copy of MyISAM files, stop mysqld first and copy the table’s data and index files from the datadir while the server is offline. Keep the original untouched and record the file paths and timestamps.
- Make sure the backup is stored on a different, healthy volume. A second copy on the same failing disk does not protect against storage loss.
- Document whether replication is enabled. Filesystem-level copying and repair is not written to the MySQL binary log, so replicas can diverge if you perform those operations while replication is running.
If you cannot obtain a usable backup and the table contains important data, stop and involve a database-recovery specialist before escalating to destructive recovery options.
Recommended Free Tools
Check a MyISAM table safely
With mysqld running, execute:
CHECK TABLE table_name;The result includes a status such as OK, Table is already up to date, or a diagnostic describing corruption. MySQL’s guidance is that a result other than OK or Table is already up to date normally means the table should be repaired.
A table can carry a “corrupted” or “not closed properly” marker even when a subsequent check finds no structural problem. MySQL documents that CHECK TABLE may remove that mark when it finds no problems. That is different from rebuilding a damaged index: do not treat removal of a stale marker as proof that an earlier error source has been fixed.
Repair MyISAM while mysqld is running
Use SQL first when an online repair is possible
For a MyISAM table, the normal SQL path is:
REPAIR TABLE table_name;This asks the server itself to repair the table and avoids an external utility modifying files that a live mysqld process may have open. Read every row returned by the statement. A successful status does not guarantee that every unrecoverable row was restored; inspect warnings and compare the result with your backup or application-level expectations.
After the repair, run the check again:
CHECK TABLE table_name;Only return the table to normal application traffic after the check completes without an error and you have confirmed that critical queries work. If the SQL repair cannot complete, or the server cannot keep the table closed long enough to repair it, use the offline path.
Control concurrent access
Applications must not write to the table while you are assessing or repairing it. Put the affected application in maintenance mode, revoke write access temporarily, or otherwise ensure that no job, import, backup script, or external process is changing the table. Concurrent writes can make a repair inconsistent or cause corruption to recur immediately.
Repair offline with myisamchk
myisamchk works directly on MyISAM table files. Oracle MySQL’s repair guidance requires that you stop the mysqld server before using it from the command line. First stop the service using the service manager appropriate to your operating system, confirm that no mysqld process still has the files open, and then work on a backup copy when possible.
Escalate in the documented order
- Quick recovery:
myisamchk -r -q table_name. The-roption requests recovery and-qasks for a quick method that does not rebuild more than necessary. - Regular recovery:
myisamchk -r table_name. Use this when quick recovery fails or reports that a more complete rebuild is required. - Safe recovery:
myisamchk --safe-recover table_name. This is slower and is intended for cases in which regular recovery cannot repair the table.
Use the actual path to the table’s .MYI file if your working directory is not the database directory. Do not start mysqld until the utility has finished and you have checked its output. After restarting the server, run CHECK TABLE table_name; and test representative reads and writes.
Choose a check depth
| Command | Purpose | Documented detection figure or trade-off |
|---|---|---|
myisamchk table_name |
Basic consistency check. | The MySQL 8.4 manual (2026 documentation) says it finds 99.99% of errors. |
myisamchk -m table_name |
More thorough check using the medium method. | The same 2026 manual says it finds 99.999% of errors. |
myisamchk -e table_name |
Complete extended check. | Can take a long time, especially for large tables; use it when a deeper diagnostic is justified. |
Those percentages describe the error-detection coverage stated in the manual, not a guarantee that a damaged table can be repaired or that data will be recovered. No authoritative general repair-success rate is established by the cited MySQL material.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →When ordinary repair cannot finish
MySQL documents a difficult-repair procedure for cases in which the normal recovery algorithm cannot rebuild the index. The procedure involves creating new empty data and index files, copying the old data file back, and then returning to the normal repair stage. It changes table files directly and therefore carries a substantial data-loss risk.
Where supported, the SQL form can perform that procedure automatically:
REPAIR TABLE table_name USE_FRM;USE_FRM tells MySQL to use the table definition file when reconstructing the index. It is not a universal solution: support depends on the table and server version, and it should be attempted only after a verified backup and a maintenance window. Stop replication before filesystem-level work because those operations are not logged by MySQL. Keep the original files so that a specialist can attempt a different recovery if this path removes needed data.
Why InnoDB needs a different diagnosis
Do not run REPAIR TABLE or myisamchk as if they were InnoDB repair tools. InnoDB stores data and indexes differently and has its own recovery mechanisms. The presence of error number 1034 does not convert an InnoDB problem into a MyISAM problem.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsMySQL 5.1 release notes describe a historical InnoDB case in which the .frm file and the InnoDB data directory became out of sync after a column rename followed by index creation. The documented workaround was to create another table with the same structure and copy the original table into it. That note is version-specific and describes a particular historical failure; it is not a universal recipe for current InnoDB corruption. For a modern InnoDB incident, preserve backups, capture the exact error-log messages, identify the server version, and follow an InnoDB-specific recovery plan rather than applying the MyISAM commands above.
If the error returns after repair
Repeated corruption is a systems problem, not merely a table that needs another repair. Check these areas in order:
Shutdown and restart history
- Review operating-system and service-manager logs for power loss, forced termination, out-of-memory kills, kernel crashes, or repeated container restarts.
- Confirm that stop procedures allow mysqld to shut down cleanly and that automated health checks are not killing a slow process.
Storage and hardware
- Inspect filesystem and disk-health reports for I/O errors, bad sectors, controller resets, or a volume running out of space.
- Verify that the datadir is on reliable storage and that backups are not filling the filesystem during writes.
Concurrent file access
- Find backup, synchronization, antivirus, migration, or administrative scripts that open or replace files in the MySQL datadir.
- Ensure every table change goes through SQL while mysqld owns the files.
MySQL diagnostics
Read the MySQL error log around the first failure, not only the final 1034 line. Look for I/O errors, aborted writes, table-open failures, or messages naming another affected table. Preserve the relevant log interval before rotation.
Automatic MyISAM recovery
MySQL can automatically check and attempt repairs when myisam_recover_options is enabled. It also logs checking and repair warnings. Treat this as a safety net, not a substitute for backups and root-cause analysis: automatic recovery can still lose unrecoverable rows, and recurring warnings require investigation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Production and replication precautions
For a production table, schedule a maintenance window and establish how you will roll back. Quiesce application writes, verify that replicas are healthy, and record the exact commands and times. SQL repair is visible to the server and follows normal database controls; direct file operations are not written to the binary log.
If the table is replicated, stop replication before copying, replacing, or repairing files offline. Afterward, validate the repaired table on the primary and each replica, compare checksums or row counts using your established procedure, and restart replication only after the files are known to be consistent. If replicas cannot be made consistent, re-seed the affected replica from a trusted backup instead of copying a live, possibly damaged file.
A practical decision tree
| Situation | Recommended next step | Reason |
|---|---|---|
| Engine is MyISAM; server is healthy and table can be taken out of service briefly. | Back up, run CHECK TABLE, then REPAIR TABLE. |
Server-side SQL avoids an external utility touching a live file. |
| SQL repair fails or mysqld cannot remain online. | Stop mysqld and escalate from myisamchk -r -q to -r, then --safe-recover. |
The offline utility can rebuild files without concurrent server access. |
| Basic checks pass but the table remains marked corrupted. | Run CHECK TABLE again and inspect whether the mark is stale; then review logs. |
A check can remove a “not closed properly” marker when no structural fault remains. |
Repair requires direct file manipulation or USE_FRM. |
Stop replication, make multiple backups, and involve an experienced operator. | Filesystem changes are not logged and may discard data. |
| Engine is InnoDB. | Do not use MyISAM repair commands; follow a version-specific InnoDB recovery plan. | The storage formats and recovery tools are different. |
| Corruption recurs. | Investigate shutdowns, hardware, external access, error logs, and software defects. | Another repair without removing the cause is likely to fail again. |
When to escalate
Escalate instead of experimenting when the table is irreplaceable, the backup cannot be verified, multiple tables are affected, the storage device reports errors, or a repair has already removed data. For a reproducible software failure, MySQL’s documented procedure is to stop mysqld, make backups, check with myisamchk, repair affected tables, reproduce the problem with logs, and contact the MySQL Customer Support Center if you have a support contract. Provide the exact server version, storage engine, error-log excerpt, commands run, and copies of the original files when permitted by your incident policy.
Quick Recap
Verification checklist after repair
CHECK TABLE table_name;returns a clean status.- Queries that previously failed can read the table.
- Primary-key and unique-key lookups return expected rows.
- Application writes succeed during a controlled test.
- Backups complete and can be restored in a test environment.
- Replication is consistent before it is resumed.
- Error logs remain free of new corruption or I/O warnings.
- The underlying shutdown, storage, or file-access cause has been addressed.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →
