How to fix ERROR 1033: Incorrect information in file in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 22, 2025· 161 views

ERROR 1033 occurs when MySQL encounters corrupted or malformed table files (.frm, .MYD, or .MYI). This typically indicates table corruption from hardware failures, unexpected shutdowns, or filesystem issues that prevent MySQL from reading critical table metadata.

Quick fix

Fixes 1033

sudo systemctl stop mysql
# OR
sudo systemctl stop mariadb
# OR on older systems
sudo /etc/init.d/mysql stop
  1. Stop the MySQL service gracefully
  2. Check the temp directory permissions
  3. Verify MySQL data directory permissions
  4. Restart MySQL and run automated table check and repair
mysql — error
sudo systemctl stop mysql
# OR
sudo systemctl stop mariadb
# OR on older systems
sudo /etc/init.d/mysql stop
ERROR 1033: Incorrect information in file

What this error means

MySQL Error 1033 (SQLSTATE: HY000, ER_NOT_FORM_FILE) indicates that MySQL encountered corrupted or incomplete information in a table file. This error most commonly occurs when: - The .frm (table definition) file is corrupted or has an invalid format - The .MYD (data) or .MYI (index) files for MyISAM tables contain corrupted data structures - InnoDB table headers are incomplete or unreadable - The file was partially written due to an unexpected shutdown or power loss This is a critical issue because it prevents MySQL from reading or writing to the affected table, causing application errors and potential data loss if not addressed promptly.

Typical symptoms

  • MySQL client fails with "ERROR 1033: Incorrect information in file" when accessing a specific table
  • The mysqldump command fails when attempting to backup the corrupted table
  • Application queries timeout or hang when trying to access the affected table
  • MySQL performance degrades or the service becomes unstable
  • Error occurs intermittently or consistently depending on which columns are accessed

Common causes

  1. Unexpected MySQL shutdown or server crash (kill -9, power failure, system reboot) leaving incomplete page headers
  2. Corrupted table files due to bad hard drive sectors or silent data corruption in the filesystem
  3. Non-writable temp directory (/tmp or /var/tmp) preventing MySQL from properly creating temporary files during operations
  4. InnoDB engine misconfiguration, such as mismatched ibdata1 file size in configuration vs. actual file size
  5. Copying MyISAM table files from a newer MySQL version to an older one, introducing incompatible header formats
  6. Incorrect file permissions on the MySQL data directory preventing proper read/write access
  7. Wrong MySQL configuration file being loaded, causing tables to open with incompatible storage engine settings

How to fix "ERROR 1033: Incorrect information in file"

1Stop the MySQL service gracefully

Before attempting any repairs, stop MySQL cleanly to prevent further corruption:

bash
sudo systemctl stop mysql
# OR
sudo systemctl stop mariadb
# OR on older systems
sudo /etc/init.d/mysql stop

Wait a few seconds to ensure all MySQL processes have terminated.

2Check the temp directory permissions

MySQL requires the temp directory to be writable. Verify and fix permissions:

bash
# Check /tmp permissions (should be 777)
ls -ld /tmp
ls -ld /var/tmp

# Fix permissions if needed
sudo chmod 777 /tmp
sudo chmod 777 /var/tmp

Also check the MySQL configuration to see which temp directory is configured:

bash
grep tmpdir /etc/mysql/my.cnf
# or
grep tmpdir /etc/my.cnf

Ensure the tmpdir path in my.cnf points to a valid, writable directory.

3Verify MySQL data directory permissions

Ensure the MySQL data directory has correct ownership and permissions:

bash
# Check current ownership and permissions
ls -ld /var/lib/mysql

# Fix ownership (should be mysql:mysql)
sudo chown -R mysql:mysql /var/lib/mysql

# Fix permissions (typically 755)
sudo chmod -R 755 /var/lib/mysql

The mysql user must have read and write access to all table files in the data directory.

4Restart MySQL and run automated table check and repair

Start MySQL and use the mysqlcheck utility to check and repair all tables:

bash
# Start MySQL
sudo systemctl start mysql

# Check and repair all tables (auto-repair mode)
mysqlcheck -u root -p --auto-repair --check --all-databases

# For a specific database only
mysqlcheck -u root -p --auto-repair --check database_name

# For a specific table
mysqlcheck -u root -p --auto-repair --check database_name table_name

The --auto-repair flag will automatically repair any corrupted tables it finds. You'll be prompted for the MySQL root password.

5For MyISAM tables: Use manual REPAIR TABLE command

If mysqlcheck doesn't fully resolve the issue, try manual repair from within MySQL:

sql
-- Connect to MySQL
mysql -u root -p

-- Attempt quick repair
REPAIR TABLE table_name QUICK;

-- If quick repair fails, try medium repair (rebuilds index)
REPAIR TABLE table_name MEDIUM;

-- Extended repair (rebuilds index from scratch)
REPAIR TABLE table_name EXTENDED;

-- Check table status after repair
CHECK TABLE table_name;

Start with QUICK, which is fastest and safest. Only use EXTENDED if MEDIUM fails.

6For InnoDB tables: Check configuration and use force recovery

If the table uses InnoDB storage engine and repair fails, check configuration and potentially use force recovery:

1. Verify InnoDB is enabled (check that skip-innodb is commented out in my.cnf)
2. Check ibdata1 file size matches configuration:

bash
# Check actual file size
ls -lh /var/lib/mysql/ibdata1

# View configuration
grep innodb_data_file_path /etc/mysql/my.cnf

3. If the size doesn't match, either:
 - Update the configuration to match the actual file size, OR
 - Delete the InnoDB data files and let MySQL recreate them (data loss!)

4. If needed, use InnoDB force recovery (last resort):

bash
# Edit my.cnf
sudo nano /etc/mysql/my.cnf

# Add this line to the [mysqld] section
innodb_force_recovery = 3

# Restart MySQL
sudo systemctl restart mysql

# Once you can start MySQL, dump the database
mysqldump -u root -p --all-databases > backup.sql

# Then stop MySQL, remove the InnoDB configuration line, and restart

WARNING: Force recovery levels 4-6 can permanently corrupt InnoDB data. Use incrementally: start at 1, increase only if MySQL won't start.

7Restore from backup if repair fails

If repair commands fail to resolve the issue, restore from your most recent backup:

bash
# Check if you have a recent mysqldump backup
ls -lt /path/to/backups/ | head -5

# Restore from backup
mysql -u root -p < backup.sql

# Or restore a specific database
mysql -u root -p database_name < database_backup.sql

If no backup exists, consider professional data recovery services as a last resort. Ensure all table structures and data are fully restored and verified.

Advanced notes

InnoDB vs MyISAM Storage Engine

Error 1033 is more common with MyISAM tables, which don't have crash-safe guarantees. InnoDB is more resilient due to its redo logs and crash recovery mechanisms. Consider converting existing MyISAM tables to InnoDB:

sql
ALTER TABLE table_name ENGINE=InnoDB;

Prevent Future Corruption

1. Enable myisam_recover_options in my.cnf for automatic repair on startup:

bash
[mysqld]
myisam_recover_options=BACKUP,FORCE

2. Use InnoDB for all new transactional tables
3. Enable regular automated backups (daily or more frequently for critical data)
4. Monitor disk health and filesystem errors (SMART tools, filesystem checks)
5. Schedule regular CHECK TABLE maintenance during low-traffic windows
6. Use UPS to prevent unexpected power loss

Troubleshooting Specific Scenarios

- Error after MySQL upgrade: Verify all tables with CHECK TABLE, backup immediately, then consider dumping and reloading the database
- Multiple tables corrupted: Indicates filesystem or hardware issues; run fsck and check disk health (badblocks, SMART status)
- mysqldump fails but MySQL runs: Use --skip-lock-tables and --max_allowed_packet options, or dump individual tables
- Error during replication: Repair on the replica first without affecting the primary; if primary is affected, failover to replica

Frequently asked questions

What does "1033" mean?
MySQL Error 1033 (SQLSTATE: HY000, ER_NOT_FORM_FILE) indicates that MySQL encountered corrupted or incomplete information in a table file. MYI (index) files for MyISAM tables contain corrupted data structures - InnoDB table headers are incomplete or unreadable - The file was partially written due to an unexpected shutdown or power loss This is a critical issue because it prevents MySQL from reading or writing to the affected table, causing application errors and potential data loss if not addressed promptly.
How do I fix "1033"?
ERROR 1033 occurs when MySQL encounters corrupted or malformed table files (.frm, .MYD, or .MYI). This typically indicates table corruption from hardware failures, unexpected shutdowns, or filesystem issues that prevent MySQL from reading critical table metadata.
What causes "1033"?
Unexpected MySQL shutdown or server crash (kill -9, power failure, system reboot) leaving incomplete page headers Corrupted table files due to bad hard drive sectors or silent data corruption in the filesystem Non-writable temp directory (/tmp or /var/tmp) preventing MySQL from properly creating temporary files during operations
Is the "1033" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading