MySQL error 1020 (ER_CHECKREAD) means a row changed between two read operations, usually during CHECK TABLE or concurrent MyISAM access, indicating potential table corruption or race conditions.
MySQL error 1020: ER_CHECKREAD occurs when a record changes between reads, typically during CHECK TABLE or concurrent MyISAM queries. Lock the table, run CHECK/REPAIR, or migrate to InnoDB to resolve the issue and prevent future occurrences.
Record has changed since last read in table '%s'
Error 1020 signals that MySQL detected a mismatch between two reads of the same row. The engine expected identical data but found differences, so it aborted the operation to prevent inconsistent results.
The message appears most often with MyISAM tables during CHECK TABLE, REPAIR TABLE, or long-running reads while other sessions modify the data.
It can also surface in replication when the slave rereads rows for consistency checks.
The error is raised during internal consistency checks. Operations like myisamchk, CHECK TABLE, and SELECT statements using non-locking reads are prime triggers. If another session updates the same row between those reads, MySQL throws ER_CHECKREAD.
Because MyISAM lacks row-level locking and full ACID guarantees, concurrent writes are permitted even while reads run.
That design trade-off makes the engine faster but more prone to this race condition.
Ignoring ER_CHECKREAD risks data corruption, failed backups, or replication stops. Addressing the root cause ensures table integrity, reliable query results, and uninterrupted application availability. Production systems should treat the warning as a signal to investigate storage engines, locking, and table health.
.
A session updates or deletes rows while another thread runs CHECK TABLE on the same MyISAM table, leading to inconsistent reads.
A long-running SELECT without LOCK TABLE overlaps with DML statements that modify the scanned rows.
Physical corruption in the .MYI or .MYD files causes mismatched records when MySQL re-reads the page.
A slave re-reads a row for relay log processing, finds a changed value, and raises ER_CHECKREAD to stop replication.
Unexpected disk errors write partial blocks, so subsequent reads return altered data.
.
No. The error is specific to engines lacking MVCC, mainly MyISAM. InnoDB uses consistent snapshots, so the race condition cannot occur.
Ignoring it risks hidden corruption and replication failures. Always investigate, repair, or migrate to a safer engine.
Temporary READ ONLY status stops writes and eliminates the race, but long-term you should migrate to an ACID-compliant engine.
Galaxy lets teams version endorsed maintenance scripts that lock tables before checks, reducing the chance of ER_CHECKREAD in shared environments.
.avif)
.avif){kind=logo}
