MySQL

MySQL "Table Doesn't Exist" After Migration

Getting a "table doesn't exist" error right after running a migration that supposedly created that exact table almost always means the migration either didn't fully succeed, or your application is looking in a different database or schema than where the table actually landed.

The Problem

You run your migration tool, it reports success, but querying the table immediately after fails:

ERROR 1146 (42S02): Table 'myapp.orders' doesn't exist

Checking the migration tool's own logs shows no errors, which makes the mismatch confusing — as far as the tool is concerned, the migration ran fine.

Why It Happens

This error usually comes down to a mismatch between where the migration actually created the table and where your application is looking for it. Common causes:

  • The migration ran against a different database than your application connects to — easy to happen with multiple environments (local, staging, production) or multiple databases on the same MySQL instance, if the connection string used for the migration didn't match the one your app uses
  • The migration partially failed silently — for example, one statement in a multi-statement migration script errored out, but the tool didn't halt or clearly report which specific statement failed
  • Case sensitivity mismatch — on Linux, MySQL table names are case-sensitive by default at the filesystem level, so a migration creating Orders and application code querying orders can be treated as two different tables entirely, even though they look the same to a casual reader
  • The migration created the table inside a transaction that was never actually committed, so the change exists only within that transaction's session and was rolled back or simply never finalized

The Fix

First, confirm which database you're actually connected to right now, and compare it against where you expect the table to be:

SELECT DATABASE();
SHOW TABLES;

If the table isn't listed here but the migration reported success, check other databases on the same server in case the migration ran against the wrong one:

SHOW DATABASES;
USE other_database_name;
SHOW TABLES;

If you find the table sitting in an unexpected database, the fix is correcting the connection string or environment configuration used by your migration tool, rather than moving the table manually — otherwise the same mismatch will recreate this exact problem on the next migration.

If case sensitivity is a suspect, check your MySQL server's table name case sensitivity setting:

SHOW VARIABLES LIKE 'lower_case_table_names';

A value of 0 means table names are case-sensitive as stored on disk (typical on Linux); a value of 1 means they're stored and compared as lowercase regardless of how you write them (typical on Windows and macOS installs). If your team develops across different operating systems, a migration and application code written with inconsistent casing can work fine for some developers and fail for others, purely based on this setting.

If a migration script contains multiple statements and one silently failed partway through, re-run the migration with verbose or debug logging enabled (the specific flag depends on your migration tool) to see each individual statement's result, rather than trusting only the tool's final summary message.

Still Not Working?

If the table genuinely doesn't exist anywhere on the server despite the migration reporting success, check whether the migration tool's own tracking table (which records which migrations have already run) was manually edited or is out of sync — some tools mark a migration as "applied" based on this tracking record alone, without re-verifying that the actual schema change is present. If someone manually inserted a row into this tracking table (common when trying to "skip" a migration during debugging), the tool will report success on future runs without ever having actually created the table.

You might also like