How to fix ERROR 1146: Table doesn't exist in MySQL

MySQLBEGINNERHIGHUpdated Dec 23, 2025· 214 views

MySQL ERROR 1146 occurs when a query references a table that MySQL cannot find in the selected database. Common causes include typos in table names, case sensitivity mismatches on Linux systems, querying the wrong database, or the table being accidentally deleted. The fix usually involves verifying the table exists and using the correct database.

Quick fix

Fixes 1146

SELECT DATABASE();
  1. Verify the correct database is selected
  2. Check the exact table name and case sensitivity
  3. Check if the table was accidentally deleted
  4. Verify the CREATE TABLE statement was executed
mysql — error
SELECT DATABASE();
ERROR 1146: Table doesn't exist

What this error means

MySQL ERROR 1146 (SQLSTATE: 42S02) indicates that the database server cannot locate a table referenced in your SQL query. This is a critical error that halts query execution immediately. The full error message format is: "ERROR 1146 (42S02): Table 'database.table_name' doesn't exist". Unlike a missing column error which might indicate a typo in column names, this error means the entire table itself is missing from the database. MySQL checks the table name against the table dictionary in your selected database, and if no match is found, it returns this error. This is often a simple issue caused by typos, case sensitivity differences (especially on Linux), or accidentally switching databases. However, it can also indicate corrupted table metadata files (.frm files for older versions or .ibd files for InnoDB) or missing ibdata system files that track table information.

Typical symptoms

  • Query execution fails immediately with "Table doesn't exist" error
  • Application crashes or returns database connection errors
  • Import scripts or migrations fail when trying to interact with a table
  • SELECT, INSERT, UPDATE, or DELETE queries all fail with the same error
  • The table appears in your application code but doesn't exist in the database
  • After restoring from backup, some tables are missing
  • Recently deleted tables still appear in application code

Common causes

  1. Typo or misspelling in the table name within the SQL query
  2. Case sensitivity mismatch ('Users' vs 'users' on Linux systems where table names are case-sensitive)
  3. Connected to the wrong database (using DEFAULT_DATABASE instead of the correct one)
  4. Table was accidentally deleted or dropped with DROP TABLE statement
  5. Table creation script was never executed (CREATE TABLE statement missing)
  6. Missing or corrupted table metadata files (.frm or .ibd files)
  7. Corrupted ibdata files (InnoDB system tablespace) preventing table discovery
  8. InnoDB crash recovery issues after improper MySQL shutdown
  9. Database restoration from backup incomplete or corrupted
  10. User permissions too restrictive to see or access the table

How to fix "ERROR 1146: Table doesn't exist"

1Verify the correct database is selected

First, confirm you're connected to the correct database. Run:

sql
SELECT DATABASE();

This shows the currently active database. If it's not the database where your table exists, switch to the correct one:

sql
USE your_database_name;

Then verify your table exists in this database:

sql
SHOW TABLES;

If you don't see your table in the output, it doesn't exist in the currently selected database.

2Check the exact table name and case sensitivity

List all tables to see the exact spelling and case:

sql
SHOW TABLES LIKE 'your_table_name';

On Linux and macOS, table names are case-sensitive by default, but on Windows they are not. If you're on Linux, ensure your query uses the exact case:

sql
-- If the table is named 'users', this fails:
SELECT * FROM Users;  -- ERROR 1146

-- But this works:
SELECT * FROM users;  -- Success

To check the exact table names in your database:

sql
SHOW TABLES;
DESCRIBE your_exact_table_name;  -- Check structure
3Check if the table was accidentally deleted

If the table recently existed but is now missing, check MySQL's binary log to see if it was dropped:

bash
mysqlbinlog /var/log/mysql/mysql-bin.000001 | grep -i "DROP TABLE"

If you find a DROP statement, you can restore from a backup:

bash
# Find the most recent backup before the DROP occurred
ls -lt /path/to/backups/

# Restore the backup (for mysqldump backups):
mysql -u root -p database_name < /path/to/backup.sql

Alternatively, if you have a backup file, restore the entire database:

bash
mysql -u root -p < /path/to/full_backup.sql
4Verify the CREATE TABLE statement was executed

If you're setting up a new database, ensure the table creation scripts ran successfully. Check if the table structure exists:

sql
DESCRIBE your_table_name;

If the error persists, the table was never created. Run your CREATE TABLE statement:

sql
CREATE TABLE your_table_name (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  email VARCHAR(255),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

For production migrations, use tools like Flyway or Liquibase to version control your schema changes:

bash
# Example: Run pending migrations
flyway migrate
5Repair corrupted InnoDB tables and system files

If you suspect table metadata corruption, attempt repair:

bash
# Check MySQL error log for corruption clues
tail -100 /var/log/mysql/error.log | grep -i "corrupt\|innodb"

For MyISAM tables, use myisamchk:

bash
# First, stop MySQL
sudo systemctl stop mysql

# Run myisamchk on the table
myisamchk -r /var/lib/mysql/database_name/table_name.MYI

# Start MySQL again
sudo systemctl start mysql

For InnoDB tables, MySQL has automatic crash recovery, but if corrupted, you may need to:

sql
-- Enable InnoDB recovery mode (add to /etc/mysql/my.cnf)
[mysqld]
innodb_force_recovery = 1  -- Start at level 1; increase if needed (1-6)

Then restart MySQL and try to dump the data, drop the table, and recreate it.

6Check user permissions to access the table

Sometimes the table exists but your MySQL user lacks permissions:

sql
-- Check your current user's permissions
SHOW GRANTS FOR 'current_user'@'localhost';

-- Or check a specific user
SHOW GRANTS FOR 'your_username'@'your_hostname';

If permissions are missing, grant them:

sql
-- Grant SELECT, INSERT, UPDATE, DELETE on a specific table
GRANT SELECT, INSERT, UPDATE, DELETE ON database_name.table_name TO 'username'@'hostname';

-- Grant all permissions on the database
GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'hostname';

-- Apply changes immediately
FLUSH PRIVILEGES;
7Restore missing ibdata files for InnoDB

InnoDB uses the ibdata system tablespace to store metadata about all tables. If this file is corrupted or missing, MySQL cannot recognize tables:

bash
# Check if ibdata1 exists
ls -la /var/lib/mysql/ibdata1

# If missing, restore from backup
cp /path/to/backup/ibdata1 /var/lib/mysql/ibdata1

# Set correct permissions
sudo chown mysql:mysql /var/lib/mysql/ibdata1
sudo chmod 660 /var/lib/mysql/ibdata1

# Restart MySQL
sudo systemctl restart mysql

If you don't have a backup of ibdata1, you may need to export all data from the old installation and import into a fresh MySQL instance.

8Restore from a database backup if all else fails

If the table metadata is severely corrupted and repair attempts fail, restore from your most recent backup:

bash
# For mysqldump backups
mysql -u root -p < /path/to/backup.sql

# For Percona XtraBackup
xtrabackup --prepare --target-dir=/path/to/backup
xtrabackup --copy-back --target-dir=/path/to/backup
sudo chown -R mysql:mysql /var/lib/mysql
sudo systemctl restart mysql

For point-in-time recovery, restore to a specific time before the table was lost:

bash
# Get binary log position before the problematic time
mysql -u root -p -e "SHOW MASTER STATUS;"

# Use mysqlbinlog to extract SQL up to a specific time
mysqlbinlog --stop-datetime='2024-12-22 14:30:00' /var/log/mysql/mysql-bin.000001 | mysql -u root -p

Advanced notes

Case sensitivity in MySQL varies by operating system. Windows treats table names as case-insensitive, but Linux and macOS are case-sensitive by default. This causes significant portability issues. Many teams use lower_case_table_names = 1 in their MySQL configuration to force case-insensitive table names across all systems:

ini
[mysqld]
lower_case_table_names = 1  # 0 = case-sensitive, 1 = case-insensitive

Note: Changing this requires rebuilding tables, so set it from the start.

For InnoDB, the .ibd file stores the actual table data, while the data dictionary (ibdata) stores metadata. If only the .ibd file exists but the metadata is missing, you can recover using the IMPORT TABLESPACE command, but this is advanced and error-prone.

When using replication, ERROR 1146 on replicas often indicates a schema mismatch between master and replica. The master may have created a table that the replica didn't receive due to network issues or filtering rules. Use SHOW SLAVE STATUS\G to check replication lag and errors.

For high-availability setups, ensure all database servers (master and replicas) are synchronized before making schema changes. Use tools like pt-table-sync from Percona Toolkit to compare and sync table definitions.

In containerized environments (Docker, Kubernetes), ensure MySQL data volumes are persisted and not ephemeral, otherwise tables will disappear when containers restart.

Frequently asked questions

What does "1146" mean?
MySQL ERROR 1146 (SQLSTATE: 42S02) indicates that the database server cannot locate a table referenced in your SQL query. This is a critical error that halts query execution immediately. table_name' doesn't exist".
How do I fix "1146"?
MySQL ERROR 1146 occurs when a query references a table that MySQL cannot find in the selected database. Common causes include typos in table names, case sensitivity mismatches on Linux systems, querying the wrong database, or the table being accidentally deleted. The fix usually involves verifying the table exists and using the correct database.
What causes "1146"?
Typo or misspelling in the table name within the SQL query Case sensitivity mismatch ('Users' vs 'users' on Linux systems where table names are case-sensitive) Connected to the wrong database (using DEFAULT_DATABASE instead of the correct one)
Is the "1146" 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