MySQL > Table doesn’t exist. But it does (or it should)

The Question :

268 people think this question is useful

I changed the datadir of a MySQL installation and all the bases moved correctly except for one. I can connect and USE the database. SHOW TABLES also returns me all the tables correctly, and the files of each table exists on the MySQL data directory.

However, when I try to SELECT something from the table, I get an error message that the table does not exist. Yet, this does not make sense since I was able to show the same table through SHOW TABLES statement.

My guess is that SHOW TABLES lists file existence but does not check whether a file is corrupted or not. Consequently, I can list those files but not access them.

Nevertheless, it is merely a guess. I have never seen this before. Now, I cannot restart the database for testing, but every other application that uses it is running fine. But that’s just a guess, I’ve never seen this before.

Does anyone know why this is happening?


| Tables_in_database    |
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

The Question Comments :
  • have you restore the database from a backup? or you just copied the db files? do you have root access to the mysql server?
  • just copied the files! yes i have root access to everything
  • can you try: mysql_fix_privilege_tables
  • are these innodb tables?
  • Yes, all tables are InnoDB. My bad for not saying it!

The Answer 1

269 people think this answer is useful

Just in case anyone still cares:

I had the same issue after copying a database directory directly using command

cp -r /path/to/my/database /var/lib/mysql/new_database

If you do this with a database that uses InnoDB tables, you will get this crazy ‘table does not exist’ error mentioned above.

The issue is that you need the ib* files in the root of the MySQL datadir (e.g. ibdata1, ib_logfile0 and ib_logfile1).

When I copied those it worked for me.

The Answer 2

46 people think this answer is useful

For me on Mac OS (MySQL DMG Installation) a simple restart of the MySQL server solved the problem. I am guessing the hibernation caused it.

The Answer 3

32 people think this answer is useful

This error can also occur when setting lower_case_table_names to 1, and then trying to access tables that were created with the default value for that variable. In that case you can revert it to the previous value and you will be able to read the table.

The Answer 4

31 people think this answer is useful

I get this issue when the case for the table name I’m using is off. So table is called ‘db’ but I used ‘DB’ in select statement. Make sure the case is the same.

The Answer 5

18 people think this answer is useful
  1. stop mysqld
  2. backup mysql folder: cp -a /var/lib/mysql /var/lib/mysql-backup
  3. copy database folder from old machine to /var/lib/mysql
  4. override ib* (ib_logfile* , ibdata ) from old database
  5. start mysqld
  6. dump dabase
  7. mysqldump >dbase.mysql
  8. stop mysql service
  9. remove /var/lib/mysql
  10. rename /var/lib/mysql-backup to /var/lib/mysql
  11. start mysqld
  12. create the database
  13. mysqldump < dbase.mysql

The Answer 6

14 people think this answer is useful

Please run the query:

    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
    information_schema.`TABLES` i
    i.TABLE_SCHEMA = 'database'

Unfortunately MySQL allows unicode and non-printable characters to be used in table name. If you created your tables by copying create code from some document/website, there is a chance that it has zero-width-space somewhere.

The Answer 7

13 people think this answer is useful

I don’t know the reason but in my case I solved just disabling and enabling the foreign keys check


The Answer 8

12 people think this answer is useful

I have just spend three days on this nightmare. Ideally, you should have a backup that you can restore, then simply drop the damaged table. These sorts of errors can cause your ibdata1 to grow huge (100GB+ in size for modest tables)

If you don’t have a recent backup, such as if you relied on mySqlDump, then your backups probably silently broke at some point in the past. You will need to export the databases, which of course you cant do, because you will get lock errors while running mySqlDump.

So, as a workaround, go to /var/log/mysql/database_name/ and remove the table_name.*

Then immediately try to dump the table; doing this should now work. Now restore the database to a new database and rebuild the missing table(s). Then dump the broken database.

In our case we were also constantly getting mysql has gone away messages at random intervals on all databases; once the damaged database were removed everything went back to normal.

The Answer 9

12 people think this answer is useful

I had the same problem and I searched for 2-3 days, but the solution for me was really stupid.

Restart the mysql

$ sudo service mysql restart

Now tables become accessible.

The Answer 10

7 people think this answer is useful

O.k. this is going to sound pretty absurd, but humor me.
For me the problem got resolved when I changed my statement to this :

SELECT * FROM `table`

I made two changes
1.) Made the table name lower case – I know !!
2.) Used the specific quote symbol = ` : It’s the key above your TAB

The solution does sound absurd, but it worked and it’s Saturday evening and I’ve been working since 9 a.m. – So I’ll take it 🙂

Good luck.

The Answer 11

7 people think this answer is useful

I had this problem after upgrading WAMP but having no database backup.

This worked for me:

  1. Stop new WAMP

  2. Copy over database directories you need and ibdata1 file from old WAMP installation

  3. Delete ib_logfile0 and ib_logfile1

  4. Start WAMP

You should now be able to make backups of your databases. However after your server restarts again you will still have problems. So now reinstall WAMP and import your databases.

The Answer 12

7 people think this answer is useful

Try to run sql query to discard tablespace before copying idb-file:


Copy idb-file


Restart MySql

The Answer 13

6 people think this answer is useful

What worked for me, was just dropping the table, even though it didnt exist. Then I re created the table and repopulated from an sql dump done previously.

There must be some metabase of table names, and it was most likely still existing in there till i dropped it.

The Answer 14

5 people think this answer is useful

After having to reinstall MySQL I had this same problem, it seems that during the install, some configuration files that store data about the InnoDB log files, these files ib_logfile* (they are log files right?), are overwriten. To solve this problem I just deleted the ib_logfile* files.

The Answer 15

5 people think this answer is useful

Had a similar problem with a ghost table. Thankfully had an SQL dump from before the failure.

In my case, I had to:

  1. Stop mySQL
  2. Move ib* files from /var/mysql off to a backup
  3. Delete /var/mysql/{dbname}
  4. Restart mySQL
  5. Recreate empty database
  6. Restore dump file

NOTE: Requires dump file.

The Answer 16

3 people think this answer is useful
  1. Do mysqldump to database:

    mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
  2. Restore database

    mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Now all tables in database were restored completely. Try..

SELECT * FROM dbname.tablename;

The Answer 17

2 people think this answer is useful

I installed MariaDB on new computer, stopped Mysql service renamed data folder to data- I solved my problem copying just Mysql\data\table_folders and ibdata1 from crashed HD MySql data Folder to the new installed mysql data folder.

I Skipped ib_logfile0 and ib_logfile1 (otherwise the server did not start service)

Started mysql service.

Then server is running.

The Answer 18

2 people think this answer is useful

It appears that the issue has to do (at least in mine and a few others) with invalid (corrupt?) innodb log files. Generally speaking, they simply need to be recreated.

Here are solutions, most of which require a restart of mysql.

  • Recreate your log files (Delete and restart mysql)
  • Resize your log files (MySql 5.6+ will regenerate the file for you)
  • If you are doing some type of a data migration, make sure you have correctly migrated the right file and given it permissions as others have already stated
  • Check permissions of your data and log files, that mysql is owner of both
  • If all else fails, you will likely have to recreate the database

The Answer 19

2 people think this answer is useful

Here is another scenario (version upgrade):

I reinstalled my OS (Mac OS El Captain) and installed a new version of mysql (using homebrew). The installed version (5.7) happened to be newer than my previous one. Then I copied over the tables, including the ib* files, and restarted the server. I could see the tables in mysql workbench but when I tried to select anything, I got “Table doesn’t exist”.


  1. stop the mysql server e.g. mysql.server stop or brew services stop mysql
  2. start the server using mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (change path as needed)
  3. run mysql_upgrade -u root -p password (in another terminal window)
  4. shut down the running server mysqladmin -u root -p password shutdown
  5. restart the server in normal mode mysql.server start or brew services start mysql

Relevant docs are here.

The Answer 20

2 people think this answer is useful

In my case, i had defined a trigger on the table and then was trying to insert the row in table. seems like, somehow trigger was erroneous, and hence insert was giving error, table doesn’t exist.

The Answer 21

1 people think this answer is useful

Its possible you have a hidden character in your table name. Those don’t show up when you do a show tables. Can you do a “SHOW CREATE TABLE TABLE_ONE” and tab complete the “TABLE_ONE” and see if it puts in any hidden characters. Also, have you tried dropping and remaking the tables. Just to make sure nothing is wrong with the privileges and that there are no hidden characters.

The Answer 22

1 people think this answer is useful

Same exact problem after TimeMachine backup import. My solution was to stop the MySQL server and fix read-write permissions on the ib* files.

The Answer 23

1 people think this answer is useful

One other answer I think is worth bringing up here (because I came here with that same problem and this turned out to be the answer for me):

Double check that the table name in your query is spelled exactly the same as it is in the database.

Kind of an obvious, newbie thing, but things like “user” vs “users” can trip people up and I thought it would be a helpful answer to have in the list here. 🙂

The Answer 24

1 people think this answer is useful

In my case, when I was importing the exported sql file, I was getting an error like table doesn’t exist for the create table query.

I realized that there was an underscore in my database name and mysql was putting an escape character just before that.

So I removed that underscore in the database name, everything worked out.

Hope it helps someone else too.

The Answer 25

1 people think this answer is useful

My table had somehow been renamed to ' Customers' i.e. with a leading space

This meant

a) queries broke

b) the table didn’t appear where expected in the alphabetical order of my tables, which in my panic meant I couldn’t see it!

RENAME TABLE ` Customer` TO `Customer`;

The Answer 26

1 people think this answer is useful

In my case it was SQLCA.DBParm parameter.

I used

SQLCA.DBParm = "Databse = "sle_database.text""

but it must be

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Explaination :

You are going to combine three strings :

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Don’t use spaces in quatermarks. Thank to my colleague Jan.

The Answer 27

1 people think this answer is useful

Go to :xampp\mysql\data\dbname
inside dbname have tablename.frm and tablename.ibd file.
remove it and restart mysql and try again.

The Answer 28

1 people think this answer is useful

Copy only ibdata1 file from your old data directory. Do not copy ib_logfile1 or ib_logfile0 files. That will cause MySQL to not start anymore.

The Answer 29

1 people think this answer is useful

Came cross same problem today. This is a mysql “Identifier Case Sensitivity” issue.

Please check corresponding data file. It is very likely that file name is in lower case on file system but table name listed in “show tables” command is in upper case. If system variable “lower_case_table_names” is 0, the query will return “table not exist” because name comparisons are case sensitive when “lower_case_table_names” is 0.

The Answer 30

1 people think this answer is useful

I had the same issue in windows. In addition to copying the ib* files and the mysql directory under thd data directory, I also had to match the my.ini file.

The my.ini file from my previous installation did not have the following line:


But my new installation did. Possibly because I did not have that option in the older installer. I removed this and restarted the service and the tables worked as expected. In short, make sure that the new my.ini file is a replica of the old one, with the only exception being the datadir, the plugin-dir and the port#, depending upon your new installation.

Add a Comment