MySQL>表不存在。 但它确实（或应该）

我确实改变了MySQL安装的datadir，并遵循一些步骤，工作正常。 我所拥有的每一个基地都被正确地移动了，

我可以连接和使用数据库，即使SHOW TABLES也能正确返回我所有的表，并且每个表的文件都存在于mysql数据目录中。 但是当我尝试select那里的东西，它说表不存在。 但表确实存在，它甚至在SHOW TABLES语句中显示！

我的猜测是，SHOW TABLES列出文件的存在不知何故文件损坏或类似的东西，但它不检查它。 所以我可以列出他们，但不能访问他们。

但这只是一个猜测，我以前从来没有见过。 现在无法重新启动数据库进行testing，所有使用它的应用程序运行良好。

有谁知道这是什么？

例：

mysql> SHOW TABLES; +-----------------------+ | Tables_in_database | +-----------------------+ | TABLE_ONE | | TABLE_TWO | | TABLE_THREE | +-----------------------+ mysql> SELECT * FROM TABLE_ONE; ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist 

Answer 1

以防万一还在乎：

直接使用命令复制数据库目录后，我遇到了同样的问题

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

如果你用一个使用InnoDB表的数据库来做到这一点，你将会得到上面提到的这个疯狂的“表不存在”的错误。

问题是您需要MySQL数据目录根目录中的ib*文件（例如ibdata1 ， ib_logfile0和ib_logfile1 ）。

当我复制它为我工作。

Answer 2

对于我的Mac OS（MySQL DMG安装），MySQL服务器的简单重新启动解决了这个问题。 我猜是冬眠造成的。

Answer 3

当我正在使用的表名的情况下，我得到这个问题。 所以表被称为“数据库”，但我在select语句中使用“数据库”。 确保案件是一样的。

Answer 4

将lower_case_table_names设置为1 ，然后尝试访问使用该variables的默认值创build的表时，也会发生此错误。 在这种情况下，您可以将其恢复到之前的值，并且您将能够读取表格。

Answer 5

1. 停止mysqld
2. 备份mysql文件夹： cp -a /var/lib/mysql /var/lib/mysql-backup
3. 从旧机器复制数据库文件夹到/var/lib/mysql
4. 覆盖旧数据库中的ib *（ib_logfile *，ibdata）
5. 启动mysqld
6. 转储数据库
7. mysqldump >dbase.mysql
8. 停止mysql服务
9. 删除/var/log/mysql
10. 将/var/lib/mysql-backup重命名为/var/lib/mysql
11. 启动mysqld
12. 创build数据库
13. mysqldump < dbase.mysql

Answer 6

请运行查询：

 SELECT 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 FROM information_schema.`TABLES` i WHERE i.TABLE_SCHEMA = 'database' 

不幸的是，MySQL允许在表名中使用unicode和不可打印的字符。 如果您通过从某个文档/网站复制创build代码来创build表格，那么它有可能在某处具有零宽度空间。

Answer 7

我只是花了三天的时间在这个噩梦。 理想情况下，您应该有一个可以恢复的备份，然后简单地删除损坏的表。 这些错误可能会导致您的ibdata1变大 （对于普通表而言，大小为100GB +）

如果你没有最近的备份，比如你依赖mySqlDump，那么你的备份在过去的某个时候可能会默默地崩溃。 你将需要导出数据库，这当然你不能这样做，因为在运行mySqlDump的时候你会遇到锁错误。

所以，作为一种解决方法，转到/var/log/mysql/database_name/并删除table_name。*

然后立即尝试转储表; 这样做现在应该工作。 现在将数据库恢复到新的数据库并重build缺失的表。 然后转储破损的数据库。

在我们的例子中，我们也不断地让mysql has gone away在所有的数据库上随机地删除消息; 一旦损坏的数据库被删除，一切恢复正常。

Answer 8

尝试在应用idb-file之前运行sql查询来丢弃表空间：

 ALTER TABLE mydatabase.mytable DISCARD TABLESPACE; 

复制idb文件

 ALTER TABLE mydatabase.mytable IMPORT TABLESPACE; 

重新启动MySql

Answer 9

好吧，这听起来很荒唐，但幽默我。
对我来说，当我改变我的陈述时，问题得到了解决：

 SELECT * FROM `table` 

我做了两个改变
1.）使表名小写 – 我知道！
2.）使用特定的引号符号= ` ：这是您的TAB上面的关键

该解决scheme听起来很荒唐，但它工作，这是星期六晚上，我一直工作，因为上午9点 – 所以我会把它:)

祝你好运。

Answer 10

在重新安装MySQL之后，我遇到了同样的问题，在安装过程中，似乎存储了一些用于存储InnoDB日志文件数据的configuration文件ib_logfile *（它们是日志文件）。 为了解决这个问题，我刚刚删除了ib_logfile *文件。

Answer 11

有一个鬼桌类似的问题。 幸运的是有一个SQL转储从失败之前。

就我而言，我不得不：

1. 停止mySQL
2. 将/var/mysql ib *文件移出备份
3. 删除/var/mysql/{dbname}
4. 重新启动MySQL
5. 重新创build空的数据库
6. 还原转储文件

注：需要转储文件。

Answer 12

什么为我工作，只是放下桌子，即使它不存在。 然后我重新创build了表，并从之前完成的SQL转储重新填充。

必须有一些表名称的元数据库，并且它很可能仍然存在，直到我放弃它。

Answer 13

升级WAMP后，我遇到了这个问题，但没有数据库备份。

这对我工作：

1. 停止新的WAMP

2. 复制你需要的数据库目录和旧的WAMP安装中的ibdata1文件

3. 删除ib_logfile0和ib_logfile1

4. 启动WAMP

您现在应该可以备份您的数据库。 但是，当你的服务器重新启动后，你仍然会遇到问题。 所以现在重新安装WAMP并导入你的数据库。

Answer 14

我有同样的问题，我search了2-3天，但对我来说，解决scheme真的很愚蠢。

重新启动mysql

$ sudo service mysql restart

现在表格可以访问。

Answer 15

我在新电脑上安装MariaDB，停止Mysql服务重命名数据文件夹到数据 – 我解决了我的问题复制只是Mysql \ data \ table_folders和ibdata1从崩溃的高清MySql数据文件夹到新安装的mysql数据文件夹。

我跳过了ib_logfile0和ib_logfile1 （否则服务器没有启动服务）

启动mysql服务。

然后服务器正在运行。

Answer 16

看来这个问题必须做（至less在我的和其他一些）与无效（腐败？）innodb日志文件。 一般来说，他们只需要重新创build。

这里是解决scheme，其中大部分需要重新启动MySQL。

• 重新创build你的日志文件（ 删除并重新启动mysql ）
• 调整您的日志文件 （MySql 5.6+将为您重新生成文件）
• 如果您正在进行某种types的数据迁移，请确保您已经正确迁移了正确的文件，并获得了其他人已经声明的权限
• 检查你的数据和日志文件的权限，mysql是两者的所有者
• 如果一切都失败了，你可能不得不重新创build数据库

Answer 17

我不知道原因，但在我的情况下，我解决了只是禁用和启用外键检查

 SET FOREIGN_KEY_CHECKS=0; SET FOREIGN_KEY_CHECKS=1; 

Answer 18

它有可能在你的表名中有一个隐藏的字符。 当你做一个表演时，这些不会显示出来。 你可以做一个“显示创build表TABLE_ONE”和选项卡完成“TABLE_ONE”，看看它是否把任何隐藏的字符。 另外，你有没有尝试删除和重新制作表格。 只是为了确保权限没有问题，并且没有隐藏的字符。

Answer 19

TimeMachine备份导入后的确切问题。 我的解决scheme是停止MySQL服务器并修复ib *文件的读写权限。

Answer 20

在我的情况下，当我导入导出的sql文件，我得到一个像表不存在的创build表查询的错误。

我意识到在我的数据库名称中有一个下划线，而且mysql正在把一个转义字符放在那之前。

所以我删除了数据库名称中的下划线，一切正常。

希望它也能帮助别人。

Answer 21

这是另一种情况（版本升级） ：

我重新安装了我的操作系统（Mac OS El Captain），并安装了一个新版本的mysql（使用自制软件）。 安装的版本（5.7）碰巧比我以前的版本更新。 然后，我复制了包括ib *文件在内的表，并重新启动了服务器。 我可以看到mysql工作台中的表，但是当我试图select任何东西，我得到“表不存在”。

解：

1. 停止mysql服务器例如mysql.server stop或brew services stop mysql
2. 使用mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/启动服务器mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ （根据需要更改path）
3. 运行mysql_upgrade -u root -p password （在另一个terminal窗口中）
4. closures正在运行的服务器mysqladmin -u root -p password shutdown
5. 以正常模式重启服务器mysql.server start或者brew services start mysql

相关文档在这里 。

Answer 22

在我的情况下，这是SQLCA.DBParm参数。

我用了

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

但一定是

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

解释：

你要结合三个string：

  1. Database=' - "Database='" 2. (name of the database) - +sle_database.text+ 3. ' - "'" (means " ' " without space) 

不要在quatermarks中使用空格。 感谢我的同事Jan。

Answer 23

转到： xampp\mysql\data\dbname
dbname里面有tablename.frm和tablename.ibd文件。
删除它，并重新启动MySQL，然后再试一次。

Answer 24

我有同样的问题，但不是由于隐藏的字符或“schroedinger的表”。 问题（完全如上所述）出现在恢复过程之后。 我正在使用MySQLpipe理员版本1.2.16。 在执行还原时，您必须在目标架构上具有未经检查的ORIGINAL ，并从下拉框中select数据库的名称。 之后问题解决了。 至less这是我的数据库的原因。

Answer 25

我认为另一个答案值得提出来（因为我来到这里也遇到了同样的问题，结果是我的答案）：

仔细检查查询中的表名是否拼写与数据库中的完全相同 。

一种明显的，新手的东西，但像“用户”和“用户”的东西可以绊倒人，我认为这将是一个有用的答案在这里列表中。 🙂

Answer 26

如果表名中有一段时间，则SELECT * FROM poorly_named.table;

使用反引号来find表SELECT * FROM `poorly_named.table`;

Answer 27

就我而言，我没有做数据迁移或任何types的文件操作。 刚刚发生了一个很好的早晨。

因为，奇怪的是，我能够使用mysqldump转储表，尽pipeMySQL有时抱怨“表不存在”，我通过转储表的schema +数据，然后删除表来解决这个问题。立即创build它，然后导入。

Answer 28

我的桌子不知何故被重新命名为' Customers'即具有领先的空间

这意味着

a）查询中断

b）桌子没有按照我的桌子的字母顺序出现在预期的地方，在我的恐慌中意味着我看不到它！

 RENAME TABLE ` Customer` TO `Customer`;