Error 1000 ER_HASHCHK appears when MySQL detects a corrupted or unsupported hash index in an ISAM or MyISAM table.
MySQL Error 1000: ER_HASHCHK (hashchk) means MySQL failed a hash index consistency check, signalling table corruption or an outdated ISAM engine. Run CHECK TABLE followed by REPAIR TABLE or migrate the table to InnoDB to resolve the issue.
hashchk
MySQL Error 1000 with condition ER_HASHCHK returns the terse message "hashchk". The code comes from legacy ISAM hash checks that verify internal index integrity.
When the check fails, the server raises this generic internal error.
Although modern MySQL builds mark the code as unused, the error can still surface when older ISAM or MyISAM tables are loaded, when a storage engine plugin maps a failure to 1000, or when underlying data corruption mimics the original failure path.
Table corruption remains the primary trigger.
Power loss, disk failure, or abrupt server shutdown can leave hash index pages unsynchronized, causing the next read to fail the checksum.
Using outdated utilities such as isamchk on a live table, mixing binaries from different MySQL versions, or copying MyISAM files across platforms without locking can introduce hash inconsistencies that raise ER_HASHCHK.
First, isolate the database or table to prevent further writes. Run CHECK TABLE to confirm corruption.
If confirmed, execute REPAIR TABLE or mysqlcheck with the --repair flag. Always back up the .MYD and .MYI files before attempting repair.
If repairs fail, restore from a known-good backup or dump the data with myisamchk --safe-recover on an offline copy, then re-import. Long-term, convert the table to InnoDB to eliminate hash index fragility.
During replication setup, an old dump containing ISAM tables can trigger ER_HASHCHK on the replica.
Solution: convert the source tables to InnoDB and re-dump.
After a sudden crash, multiple MyISAM tables raise ER_HASHCHK at startup. Use mysqlcheck --all-databases --auto-repair, then schedule regular fsyncs and UPS protection.
Prefer InnoDB for all new tables; its B-tree indexes avoid the legacy hash path. Keep MySQL server and client utilities on the same version to prevent format mismatches.
Automate nightly mysqlcheck --optimize and store backups in offsite storage.
Monitor error logs for early signs of index warnings to act before ER_HASHCHK appears.
Error 126 (ER_INDEX_REBUILD): indicates missing or corrupt MyISAM index file; the repair workflow is similar.
Error 127 (ER_CHECKNO): signals record file damage in MyISAM; use myisamchk --recover. Both often occur alongside ER_HASHCHK when disk issues strike.
Galaxy’s modern SQL editor surfaces real-time MySQL error messages and suggests context-aware fixes.
Built-in AI completions recommend CHECK TABLE and REPAIR TABLE commands, while versioned query history lets teams document the exact repair steps for future audits.
.
No. The error is tied to legacy ISAM/MyISAM hash indexes. InnoDB uses B-tree indexes and will not raise ER_HASHCHK.
Not necessarily. In most cases the data file (.MYD) is intact and only the index (.MYI) needs repair or rebuild.
Yes. mysqlcheck --repair places a write lock on each table while rebuilding indexes, so schedule maintenance windows.
Galaxy highlights the error, autofills CHECK TABLE/REPAIR TABLE commands, and stores your repair scripts in versioned Collections for future reuse.
.avif)
.avif){kind=logo}
