MySQL>表不存在.但它确实(或它应该)

Question

我确实更改了MySQL安装的datadir,并按照一些步骤运行正常.我所拥有的每个基地都正确地移动了一个.

我可以连接和使用数据库,甚至SHOW TABLES正确返回所有表,并且mysql数据目录中存在每个表的文件.但是当我尝试在那里选择某些东西时,它表示该表不存在.但表确实存在,它甚至在SHOW TABLES声明中显示!

我的猜测是,SHOW TABLES列出了文件以某种方式存在文件损坏或类似的东西,但它没有检查它.所以我可以列出它们但不能访问它们.

但这只是猜测,我以前从未见过这个.现在无法重新启动数据库进行测试,使用它的每个其他应用程序运行正常.

有谁知道它是什么？

例:

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表的数据库,你会得到上面提到的这个疯狂的"表不存在"错误.

问题是您需要ib*MySQL datadir根目录中的文件(例如ibdata1,ib_logfile0和ib_logfile1).

当我复制那些它为我工作.

Answer 2

对于我在Mac OS(MySQL DMG安装)上,简单重启MySQL服务器解决了这个问题.我猜测冬眠导致了它.

Answer 3

当我正在使用的表名的情况关闭时,我得到了这个问题.所以table被称为'db',但我在select语句中使用'DB'.确保案例相同.

Answer 4

设置lower_case_table_names为1,然后尝试访问使用该变量的默认值创建的表时,也会发生此错误.在这种情况下,您可以将其还原为以前的值,您将能够读取该表.

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. dump dabase
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

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和不可打印的字符.如果您通过从某个文档/网站复制创建代码来创建表,那么它有可能在某处具有零宽度空间.

Answer 7

我有同样的问题,我搜索了2-3天,但对我来说解决方案真的很愚蠢.

重启mysql

$ sudo service mysql restart

现在表变得可访问了.

Answer 8

我在这场噩梦上度过了三天.理想情况下,您应该有一个可以恢复的备份,然后只需删除损坏的表.这些类型的错误可能导致您的ibdata1变大(适用于适度表格的100GB +大小)

如果你没有最近的备份,例如你依赖mySqlDump,那么你的备份可能会在过去的某个时候默默地破坏.您将需要导出数据库,这当然是您无法做到的,因为在运行mySqlDump时您将遇到锁定错误.

因此,作为一种解决方法,请转到/var/log/mysql/database_name/并删除table_name.*

然后立即尝试转储表; 这样做现在应该有效.现在将数据库还原到新数据库并重建丢失的表.然后转储损坏的数据库.

在我们的案例中,我们也经常mysql has gone away在所有数据库上随机获取消息; 一旦损坏的数据库被删除,一切都恢复正常.

Answer 9

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

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Answer 10

在复制idb-file之前尝试运行sql查询以丢弃表空间:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

复制idb文件

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

重启MySql

Answer 11

好吧,这听起来很荒谬,但幽默我.
对我来说,当我将声明更改为此时问题得到了解决:

SELECT * FROM `table`

我做了两个更改
1.)使表名小写 - 我知道!!
2.)使用特定的引号= `:它是你的TAB上方的键

解决方案确实听起来很荒谬,但它确实有效,这是星期六晚上,我从上午9点开始工作 - 所以我会接受它:)

祝好运.

Answer 12

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

这对我有用:

1. 停止新的WAMP

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

3. 删除ib_logfile0和ib_logfile1

4. 启动WAMP

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

Answer 13

对我有用的是，即使它不存在，也只是放下桌子。然后我重新创建了表并从之前完成的 sql 转储中重新填充。

必须有一些表名的元数据库，并且在我删除它之前它很可能仍然存在于那里。

Answer 14

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

Answer 15

与幽灵表有类似的问题.谢天谢地,在失败之前有一个SQL转储.

在我的情况下,我不得不:

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

注意:需要转储文件.