MySQL祝辞表不存在。但它确实(或应该)

我改变了MySQL安装的datadir，所有的基都正确移动，除了一个。 我可以连接和USE数据库。SHOW TABLES也正确地返回给我所有的表，并且每个表的文件都存在于MySQL数据目录中

然而，当我试图从表中SELECT一些东西时，我得到一个错误消息，表不存在。然而，这没有意义，因为我能够通过SHOW TABLES语句显示相同的表。

我的猜测是SHOW TABLES列出文件存在，但不检查文件是否损坏。因此，我可以列出这些文件，但不能访问它们。

然而，这只是一个猜测。我以前从未见过这个。现在，我无法重新启动数据库进行测试，但使用它的其他所有应用程序都运行正常。 但这只是猜测，我从来没见过。< / p >

有人知道为什么会这样吗?

例子:

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
600346 次浏览
小开

当我使用的表名的大小写关闭时，我就会遇到这个问题。所以表被称为'db'但我在select语句中使用'db'。确保箱子是一样的。

小开

它可能有一个隐藏字符在你的表名。当你做表的时候，这些是不会显示出来的。你可以做一个“SHOW CREATE TABLE TABLE_ONE”和tab完成“TABLE_ONE”，看看它是否放入了任何隐藏字符。还有，你有没有试过把桌子掉下来重新做。只是为了确保特权没有问题，并且没有隐藏字符。

小开

请运行查询:

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和非打印字符。 如果你通过复制一些文档/网站的create代码来创建你的表，那么它有可能在某个地方有0 -width-space
小开

我也遇到了同样的问题，但这不是由于一个隐藏的字符或“薛定谔表”。问题(与上面所述的完全相同)出现在恢复过程之后。我使用的是MySQL管理员版本1.2.16。当必须执行还原时，必须在目标模式中未选中ORIGINAL，并从下拉框中选择数据库的名称。之后问题就解决了。至少在我的数据库里是这样的。

小开

以防还有人关心:

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

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

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

问题是你需要MySQL数据根目录下的ib*文件(例如ibdata1， ib_logfile0和ib_logfile1)。

当我复制它们时，它对我有用。

小开

在重新安装MySQL后，我遇到了同样的问题，似乎在安装过程中，一些存储关于InnoDB日志文件数据的配置文件，这些文件ib_logfile*(它们是日志文件对吧?)，被覆盖了。为了解决这个问题，我删除了ib_logfile*文件。

小开

我花了三天时间在这个噩梦上。理想情况下，您应该有一个可以恢复的备份，然后只需删除损坏的表。这类错误会导致ibdata1增加巨大的(一般表的大小为100GB+)。

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

因此，作为一种变通方法，去/var/log/mysql/database_name/并删除table_name.*

然后立即尝试转储表;这样做现在应该可以工作了。现在将数据库恢复到一个新的数据库，并重新构建丢失的表。然后转储损坏的数据库。

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

小开
  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/lib/mysql
  10. 将/var/lib/mysql-backup重命名为/var/lib/mysql
  11. 开始mysqld
  12. 创建数据库
  13. mysqldump < dbase.mysql
小开

幽灵桌也有类似的问题。幸运的是，在失败之前有一个SQL转储。

就我而言，我必须:

  1. 停止mySQL
  2. 将ib*文件从/var/mysql移到备份
  3. 删除/var/mysql/{dbname}
  4. 重新启动mySQL
  5. 重新创建空数据库
  6. 恢复转储文件

注意:需要转储文件。

小开

在我的例子中，它是SQLCA.DBParm参数。

我使用

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

但它必须是

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

解释:

你将组合三个字符串:

 1. Database='              -  "Database='"


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


3. '                       - "'" (means " ' "  without space)
不要在四元符号中使用空格。 感谢我的同事Jan.

小开

对我来说有效的方法是扔掉桌子，即使它根本不存在。然后，我重新创建了表，并从以前完成的sql转储中重新填充。

一定有一些表名的元数据库，它很可能仍然存在，直到我删除它。

小开

对我来说，在Mac OS (MySQL DMG安装)，一个简单的重启MySQL服务器解决了这个问题。我猜是冬眠造成的。

小开
我在新电脑上安装了MariaDB， 停止Mysql服务 重命名数据文件夹为data- 我解决了复印的问题 Mysql\data\table_folders和ibdata1 从崩溃的高清MySql数据文件夹到新安装的MySql数据文件夹

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

启动mysql服务。

然后服务器正在运行。

小开

导入TimeMachine备份后也会出现同样的问题。我的解决方案是停止MySQL服务器并修复ib*文件的读写权限。

小开

在复制idb-file之前，尝试使用sql查询来丢弃表空间:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

复制idb-file

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

重新启动MySql

小开

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

小开

这个问题似乎与无效(损坏?)的innodb日志文件有关(至少在我的和其他几家)。一般来说，它们只是需要重新创建。

这里有一些解决方案，其中大部分需要重新启动mysql。

  • 重新创建日志文件(删除并重新启动mysql)
  • 调整日志文件的大小 (MySql 5.6+将为您重新生成文件)
  • 如果您正在进行某种类型的数据迁移，请确保您正确地迁移了正确的文件，并按照其他人已经声明的那样赋予其权限
  • 检查数据和日志文件的权限，确保mysql是两者的所有者
  • 如果所有这些都失败了，您可能不得不重新创建数据库
小开

另一个我认为值得在这里提出的答案(因为我带着同样的问题来到这里，而这对我来说就是答案):

再次检查查询中的表名是否为拼写完全一样，因为它在数据库中。

有点明显的，新手的事情，但像"user"和"users"这样的东西会让人绊倒，我认为在这里的列表中有一个有用的答案。：）

小开

如果表名中有句点，它将失败 SELECT * FROM poorly_name .table; < /代码> < / p >

使用反勾号让它找到表 SELECT * FROM ' poorly_name .table '; < /代码> < / p >

小开
< p >好吧这听起来很荒谬，但请迁就我 对我来说，当我把我的语句改为

时，问题得到了解决 
SELECT * FROM `table`
我做了两个改动
1)。使表名小写-我知道!!< br > 2)。使用特定的引号符号= ｀:它是你的TAB上面的键

这个解决方案听起来很荒谬，但它很有效，而且现在是周六晚上，我从早上9点就开始工作了-所以我接受了:)

祝你好运。

小开

在我的情况下，当我导入导出的sql文件时，我得到了一个错误，比如创建表查询的表不存在。

我意识到在我的数据库名中有一个下划线，mysql在这之前放了一个转义字符。

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

希望这也能帮助到其他人。

小开

下面是另一个场景(版本升级):

我重新安装了我的操作系统(Mac OS El Captain)，并安装了一个新版本的mysql(使用自制软件)。安装的版本(5.7)恰好比我之前的版本更新。然后复制表，包括ib*文件，并重新启动服务器。我可以看到mysql工作台中的表，但当我尝试选择任何东西时，我得到“表不存在”。

解决方案:

  1. 停止mysql服务器，例如mysql.server stop或brew services stop mysql
  2. 使用mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/启动服务器(根据需要更改路径)
  3. 运行mysql_upgrade -u root -p password(在另一个终端窗口中)
  4. 关闭运行中的服务器mysqladmin -u root -p password shutdown
  5. 以正常模式mysql.server start或brew services start mysql重新启动服务器

相关文档为在这里。

小开

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

这招对我很管用:

  1. 停止新的WAMP

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

  3. 删除ib_logfile0和ib_logfile1

  4. 开始里面

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

小开

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

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
小开

在我的例子中，我没有做datadir重定位或任何类型的文件操作。这件事发生在一个晴朗的早晨。

因为，奇怪的是，我能够转储表，使用mysqldump，尽管MySQL有时会抱怨“表不存在”，我解决它通过转储表的模式+数据，然后drop表，然后重新创建它之后立即，然后导入。

小开

我的表以某种方式被重命名为' Customers'，即领先的空间

这意味着

解析:答案为A。

b)表没有出现在我的表的字母顺序中，这在我的恐慌中意味着我看不到它!

RENAME TABLE ` Customer` TO `Customer`;
小开

我也遇到了同样的问题，我找了2-3天，但这个解决方案对我来说真的很愚蠢。

重新启动mysql

$ sudo service mysql restart

现在可以访问表了。

小开

去:xampp\mysql\data\dbname
在dbname中有tablename.frm和tablename.frm。ibd文件。
删除

. >请重新启动mysql，然后重试
小开

在我的情况下，我已经在表上定义了一个触发器，然后试图在表中插入行。好像是触发出错了，插入出错了，表不存在。

小开
  1. mysqldump到数据库:

    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;
小开

仅从旧数据目录复制ibdata1文件。不要复制ib_logfile1或ib_logfile0文件。这将导致MySQL不再启动。

小开

今天遇到了同样的问题。这是一个mysql的“标识符大小写敏感性”问题。

请检查相应的数据文件。很有可能文件系统上的文件名是小写的，而“show tables”命令中列出的表名是大写的。如果系统变量"lower_case_table_names"为0，查询将返回"表不存在"，因为当"lower_case_table_names"为0时，名称比较是区分大小写的。

小开

我在windows中有同样的问题。 除了复制ib*文件和thd data目录下的mysql目录外，我还必须匹配my.ini文件

我之前安装的my.ini文件没有下面这行:

innodb-page-size=65536
但是我的新安装做到了。可能是因为我在旧的安装程序中没有这个选项。 我删除了它并重新启动了服务，表按预期工作。 简而言之，确保新的my.ini文件是旧文件的副本，唯一的例外是datadir, plugin-dir和port#，这取决于您的新安装

提交答案