Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Do not start by running a repair command. First preserve a tested backup or snapshot, identify the table’s storage engine, and run a normal CHECK TABLE (or mysqlcheck). REPAIR TABLE and mysqlcheck --repair work only with MyISAM, ARCHIVE, and CSV tables. They are not InnoDB repair tools. InnoDB recovery normally means starting with the lowest workable innodb_force_recovery setting, extracting a logical dump, and rebuilding or restoring into a clean instance.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What database corruption looks like
Corruption means that one or more table files, indexes, or data pages no longer match the structure MySQL expects. The visible symptom may be a failed query, an incorrect row read, an update error, a table that will not open, or a server crash when a damaged page is accessed. A failed application request does not prove corruption by itself: permissions, a full disk, a broken connection, and SQL errors can produce similar symptoms.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
Take a conservative approach when a production game service, leaderboard, inventory system, or account database is affected. A corrupt InnoDB page can cause the server to exit, so checks and recovery work should happen during a controlled maintenance window with a recovery copy available.
Protect the evidence before changing anything
Repair can alter or discard damaged records. Oracle’s MySQL documentation warns that it is best to back up a table before a repair because, under some circumstances, the operation can cause data loss. Treat that warning as a prerequisite, not an optional precaution.
#1 Best Overall
- Create and verify a current backup, filesystem snapshot, or storage-level copy. A backup that has never been tested is not a dependable recovery plan.
- When possible, stop writes and work on a clone. Keep the original files untouched so another recovery attempt remains possible.
- Record the exact error text, database and table names, MySQL server version, storage engine, and whether the server is stable or repeatedly crashing.
- Do not delete table files, initialize a new data directory over the old one, or repeatedly run repair commands while you are still collecting evidence.
If the server is unstable, prioritize a safe copy and a controlled shutdown over repeated diagnostic queries. If it is stable, capture the diagnostic output before attempting a change.
Check the table and identify its storage engine
Run a standard check first. Replace the example identifiers with the affected database and table:
CHECK TABLE `db_name`.`table_name`;The command reports the table’s check status and a message describing any problem MySQL found. Save the complete result rather than only the final line.
The command-line maintenance program provides the equivalent check:
mysqlcheck --check db_name table_nameTo check every table in a database, provide the database name without an individual table. To check every database, use:
mysqlcheck --all-databasesBefore choosing a repair method, establish the engine. The engine determines whether a repair operation is supported; a table name alone is not enough. Include the engine in your incident notes along with the check result and server state.
A normal check should precede an extended check. MySQL documents EXTENDED as a slower follow-up when an ordinary check does not explain read or update errors. Use it selectively, because it increases the time and load of the diagnostic operation:
CHECK TABLE `db_name`.`table_name` EXTENDED;Do not use an extended check as a substitute for a backup or as permission to skip engine identification.
Choose the recovery path by storage engine
| Storage engine | Supported repair route | What to do if the route fails |
|---|---|---|
| MyISAM | REPAIR TABLE, mysqlcheck --repair, or offline myisamchk with the server stopped |
Use a logical dump, rebuild, or restore a known-good backup after preserving the original |
| ARCHIVE | REPAIR TABLE or mysqlcheck --repair |
Extract what is readable, then rebuild or restore from a known-good backup |
| CSV | REPAIR TABLE or mysqlcheck --repair |
Extract what is readable, then rebuild or restore from a known-good backup |
| InnoDB | Not repaired by REPAIR TABLE or mysqlcheck --repair; use emergency recovery, dump/reload, rebuild, or restoration |
Restore a validated backup in a separate instance when extraction or startup recovery cannot complete |
MySQL’s rule is explicit: “The REPAIR TABLE method is only applicable to MyISAM, ARCHIVE, and CSV tables.” Applying it to InnoDB does not repair the damaged InnoDB data.
Repair MyISAM, ARCHIVE, and CSV tables
Use SQL when the server is running
After preserving a backup and confirming that the table uses a supported engine, run:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →REPAIR TABLE `db_name`.`table_name`;The operation may rewrite indexes or remove structures that cannot be recovered. Keep the returned messages with the incident record. When it completes, run a fresh CHECK TABLE and compare the result with the pre-repair output.
The command-line equivalent is:
mysqlcheck --repair db_name table_nameUse one method, not several competing repair attempts at once. Concurrent writes can change the table while a repair is operating and make the result harder to interpret. Schedule a maintenance window or otherwise prevent application writes for the affected table when your service design allows it.
Confirm that the repair actually solved the problem
- Run
CHECK TABLEagain and retain the complete output. - Compare row counts with the last trusted backup or an application-level count. A successful command does not guarantee that every damaged row was recoverable.
- Exercise the queries that failed, including reads and writes used by the game or service.
- Check application logs for continuing errors, timeouts, or missing records.
If the check remains inconsistent, the server crashes, or important records are missing, stop additional repair attempts. Move to extraction or restoration rather than repeatedly modifying the same files.
Use offline myisamchk only with mysqld stopped
myisamchk can check or repair MyISAM table files outside the server process. It is an offline tool: mysqld must not be changing the table at the same time. Running it while the server updates a table can produce a corruption warning even when the table is not corrupt.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minute- Stop
mysqldcleanly and confirm that no second server instance or automated job is writing to the data directory. - Take or verify a copy of the table files before using the utility.
- Run the version-appropriate
myisamchkcheck or repair against the copied MyISAM files, following the utility syntax shipped with your MySQL installation. - Start
mysqld, runCHECK TABLE, and test the affected application queries.
Do not use this offline procedure for InnoDB files. InnoDB recovery follows a different path and must use InnoDB’s emergency-start and extraction procedures.
Recover a corrupt InnoDB table
InnoDB requires a different response because REPAIR TABLE is not an InnoDB repair tool. MySQL advises that if CHECK TABLE indicates corruption or causes InnoDB to fail, use the innodb_force_recovery guidance to restart InnoDB.
Start with the least invasive emergency setting
Set the lowest innodb_force_recovery level that allows the server to start. This is an emergency measure intended to make data readable long enough to extract it, not a permanent operating mode. Higher levels can suppress more background activity, but they also reduce normal safety and write capability; increase the level only when a lower one cannot start the instance.
Because a corrupt page can terminate the server, perform this work on a copy or in a controlled maintenance window. Keep the emergency configuration clearly marked so it cannot be mistaken for a normal production setting.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Extract readable data with a logical dump
Once the server starts, extract the affected table or database with mysqldump:
mysqldump db_name table_name > dump.sqlIf one table prevents a complete dump, dump readable tables individually and record which objects could not be extracted. A dump that finishes is not automatically complete: review warnings and errors, and confirm that expected tables and rows are present.
Rebuild in a clean instance
Import the dump into a separate, clean database instance rather than overwriting the damaged data directory:
mysql clean_db < dump.sqlAfter import, run checks, verify row counts against your trusted backup or application records, and test the queries that exposed the failure. Recreate required indexes, constraints, users, and permissions as part of the rebuild plan when they are not represented in the table dump.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Remove emergency recovery mode
After extraction, remove the emergency innodb_force_recovery setting before normal operation. Validate the rebuilt instance independently, then move traffic during a controlled change window. Do not treat a server that merely starts under force recovery as repaired.
When to dump, rebuild, or restore
Use the following decision points after the initial check. They separate a recoverable table-level problem from an instance that should be replaced.
| Observed condition | Preferred next step | Reason and validation |
|---|---|---|
| Supported non-InnoDB engine; server stable; backup preserved | Run one documented repair, then check again | Repair is supported, but compare row counts and application behavior afterward |
| InnoDB; server starts only with emergency recovery | Dump readable data and rebuild in a clean instance | Force recovery is for extraction; remove it after the dump and validate the rebuilt database |
| Checks remain inconsistent after repair | Stop modifying the original and use a dump or restore | Repeated repairs can increase loss and obscure the original evidence |
| Server repeatedly crashes or extraction cannot complete | Restore a known-good backup to a separate instance | Validate the restored copy before a controlled cutover |
| Freshness of backup is insufficient for business requirements | Combine the newest usable backup with any readable post-backup data | Document the gap and obtain application-owner approval for unavoidable loss |
A restore is not finished when the files are copied. Start the restored instance separately, run integrity checks, test critical queries, and confirm that the application can read and write expected records before directing production traffic to it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Validate the repaired or rebuilt database
Database-level checks
- Run
CHECK TABLEon every affected table, not only the table named in the first error. - For a broad incident, use
mysqlcheck --all-databasesor check the complete affected database. - Use
EXTENDEDonly when the normal check does not explain the observed read or update errors.
Application-level checks
- Replay the read, insert, update, and delete paths that were failing.
- Verify critical game data such as account records, inventory, progression, and leaderboard entries against an independent source when one exists.
- Watch logs and error rates during a canary period after cutover.
Operational checks
- Confirm that the server is no longer running with
innodb_force_recovery. - Confirm that scheduled backups run and that a restore test is recorded.
- Keep the original damaged copy and all command output until the incident is closed and retention requirements are met.
Common mistakes and safer alternatives
Running REPAIR TABLE on InnoDB
This is the most damaging misconception. The command is documented for MyISAM, ARCHIVE, and CSV only. Identify the engine first; for InnoDB, use emergency startup and extraction or restore.
Skipping the backup because the table is already damaged
A repair can remove information that a later technique might recover. Preserve a copy before the first write-changing operation.
Using myisamchk while mysqld is online
Concurrent writes can make a healthy table appear corrupt and can worsen a real problem. Stop the server and eliminate other writers before offline work.
Checking only one table
An application error may involve related tables or a broader storage problem. Start with the reported table, then broaden the check when symptoms or output indicate an instance-wide issue.
Leaving force recovery enabled
Force recovery is an emergency extraction state. Remove it after the dump and run the rebuilt instance normally before cutover.
Assuming “repair completed” means “no data was lost”
Compare counts and business-critical records with a trusted backup or independent application data. A command can complete while damaged rows, indexes, or relationships remain incomplete.
Investigate the cause after service is restored
Repair treats the symptom. Once a clean instance is validated, investigate why corruption occurred so the replacement does not fail in the same way. Review storage and filesystem errors, abrupt shutdowns, power or host failures, and hardware alerts. Correlate those events with database logs and the time of the first failed query.
Document the timeline, affected tables, engine, checks performed, repair or extraction commands, backup used, records that could not be recovered, and validation results. Use that record to improve backup frequency, snapshot retention, restore testing, and maintenance procedures.
Practical command sequence
For a stable server and a supported non-InnoDB table, the safe sequence is:
- Preserve and verify a backup or snapshot; work on a clone when possible.
- Run
CHECK TABLE `db_name`.`table_name`;and save the output. - Confirm that the engine is MyISAM, ARCHIVE, or CSV.
- Run
REPAIR TABLE `db_name`.`table_name`;ormysqlcheck --repair db_name table_nameduring a controlled window. - Run
CHECK TABLEagain, compare records, and test the application.
For InnoDB, replace step four with the emergency recovery, mysqldump extraction, clean rebuild, and validation process described above. If the server cannot remain stable or extraction cannot finish, restore a known-good backup to a separate instance and validate it before cutover.
Quick Recap
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.
