Schr & # 246; dingers MySQL 表: 存在,但它不存在

我犯了一个最奇怪的错误。

有时,在创建或更改表时,会出现“表已经存在”错误。但是,DROPTABLE 返回“ # 1051-未知表”。所以我得到了一个表,我不能创建,不能删除。

当我尝试删除数据库时,mysqld 崩溃了。有时创建另一个具有不同名称的 db 会有所帮助,有时则不会。

我使用一个有大约50个表的数据库,全部是 InnoDB。这个问题发生在不同的表上。

我在 Windows,Fedora 和 Ubuntu,MySQL 5.1和5.5上都经历过这种情况。在使用 PDO、 PHPMyAdmin 或命令行时,行为相同。我使用 MySQL Workbench 来管理我的模式——我看到了一些相关的错误(端线和其他东西) ,但是没有一个与我相关。

No, it is not a view, it is a table. All names are lowercase.

我试了所有能用谷歌搜索的方法,冲洗桌子,搬家。从 db 文件到 db 文件,阅读 mysql 日志,没有什么帮助,但重新安装整个该死的东西。

‘显示表’什么都没有显示,‘描述表’说‘表不存在’,就没有。然而,“ create table”仍然以错误结束(“ create table if not been”也是如此) ,并且删除数据库会导致 mysql 崩溃

相关但无益的问题:

编辑:

mysql> use askyou;
Database changed


mysql> show tables;
Empty set (0.00 sec)


mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists


mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

因此,都一样: 表不存在,却不能被创建;

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Names change, this is not the only table / database I've run into problems with

42980 次浏览

当数据目录中缺少数据文件,但是存在表定义文件或者反之亦然时,我就会看到这个问题。如果正在使用 inodb _ file _ per _ table,请检查数据目录,以确保同时具有 .frm文件和。表的 ibd 文件。如果是 MYISAM,应该有一个 .frm.MYI.MYD文件。

通常可以通过手动删除孤立文件来解决这个问题。

在这里大胆地猜测一下,但是看起来在表空间中(可能是在 ibdata中) ,inodb 仍然为您的表提供了一个条目。如果您的 真的不需要数据的 任何,或者如果您有备份,请尝试以下操作:

  1. 删除所有模式(不包括 mysql)
  2. 关闭数据库
  3. 确保正确删除了数据目录中的所有文件夹(同样,不包括 mysql)
  4. 删除 ibdata 和日志文件
  5. 重新启动数据库。它应该从头开始重新创建表空间和日志。

我怀疑这是对这个问题的直接回答,但是这里是我如何在我的 OS X Lion 系统上解决 这个问题的。

我经常为我计划的一些分析工作创建/删除表格。在某个时候,我开始在脚本的中途获取表已经存在的错误。重新启动服务器通常可以解决这个问题,但是这个解决方案太烦人了。

然后我注意到在本地错误日志文件中有这么一行:

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

这给了我一个想法,也许如果我的表包含大写字母,MySQL 会被愚弄,以为它们仍然存在,即使我已经丢弃了它们。事实证明的确如此,转而只使用小写字母来表示表名就解决了这个问题。

It is likely the result of some misconfiguration in my case, but hopefully this error case will help someone waste less time trying to find a solution.

在我的例子中,通过将 mysql 数据目录的所有权更改为运行应用程序的用户,问题得到了解决。(在我的案例中,它是一个运行 Jetty webserver 的 Java 应用程序。)

尽管 mysql 正在运行,其他应用程序可以正确使用它,但这个应用程序有一个问题。在更改数据目录所有权并重置用户密码之后,一切都正常工作。

如果将是股票与这个错误1051,你只想删除数据库和导入这一次做这些步骤,一切都会很好..。

在 Unix 环境中作为 :

  • Rm-rf/var/lib/mysql/YOUR _ DATABASE;
  • 可选-> mysql _ update-force
  • Mysqlcheck-uUSER-pPass YOUR _ Database
  • Mysqladmin-uUSER-pPass 删除你的数据库
  • Mysqladmin-uUSER-pPass 创建你的数据库
  • Mysql-uUSER-PASS YOUR _ Database < IMPORT _ FILE 通过您的 _ 数据库 < IMPORT _ FILE

Regards, Christus

我有这个问题,并希望删除 IBD 文件将有所帮助,如上所述,但它没有什么区别。MySQL 只重新创建了一个新的 IBD 文件。在我的例子中,实际上在同一个 MySQL 实例中的其他数据库中也有类似的表。由于 FRM 文件丢失,我从另一个数据库中的相似表中复制了 FRM 文件,重新启动了 MySQL,该表运行正常。

我在一张特定的桌子上遇到了这个问题:

  • 搜索孤儿文件: 不存在任何人;
  • 执行: show full tables in database;: 没有看到有问题的那个;
  • 执行: describe table;: 返回 table doesn't exist;
  • 执行: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';: 返回 Empty set;
  • Search by the phpMyAdmin manually the query above: didn't exist;

在这些步骤之后,我再次检查 show tables;和... Vualá!有问题的桌子不见了。我可以创建和删除它与相同的问题名称没有问题,我甚至不必重新启动服务器!真奇怪。

I ran into this error after I created a table and deleted it, then wanted to create it again. 在我的例子中,我有一个自包含的转储文件,所以我删除了模式,重新创建了它,并使用转储文件导入了表和数据。

解决办法很简单,至少我想出来的办法对我有效。 在另一个 MySQL 实例上创建一个表“ zzz”,其中 zzz 是问题表名。 (也就是说,如果这个表叫薛定谔,那么不管写成什么,就用 zzz 代替它。) 表的定义是什么并不重要,它只是一个临时的假象; 将 zzz.frm 文件复制到表所在的服务器上的数据库目录, 确保文件的所有权和权限仍然正确。 在 MySQL 上,您现在可以执行“ show tables;”,并且 table zzz 将出现在那里。 Mysql > 下拉表 zzz; ... 现在应该可以工作了。如果需要,清除目录中的任何 zzz.MYD 或 ZZZ.MYI 文件。

It happens at our site (but rarely) usually when an "event" happens while running certain scripts that do a lot of rebuilding. Events include network outages or power problems.
这种情况极少发生时,我会采取强硬手段:

  • 我只需要简单地处理并重建这张特定的表。我通常在一个位置,这是确定的,因为表正在建立。(如果需要恢复数据,您的情况可能会有所不同)
  • As an admin, go into the mysql installation (on windows its may be "...program files/mysql/MySQL Server xx/data/<schemaname>
  • 在 < schemaname > 文件夹中找到具有表名的违规文件,然后删除它。
  • 检查孤立的临时文件,并删除它们。 # ... 从文件,如果他们碰巧在那里。
  • MySQL will let you CREATE the table again

在很长一段时间(多年)里,我在几个不同的数据库中都遇到过这个问题。这是一个难题,因为相互矛盾的信息。第一次,我做了一个删除/重建/重命名数据库的变种,如其他答案所述,并设法让事情进行下去,但它肯定需要更长的时间。对我来说幸运的是,它总是发生在正在重建的参考表上—— DROP 和 CREATEd ——通常是在早上。虽然很少遇到这个问题,但是逐渐认识到这是一个特殊的离奇案例。(我将重申: 如果需要恢复数据,请参考其他解决方案。)

  • 它不是属于另一个用户或另一个数据库中的表
  • 这不是大小写的问题,我用的都是小写,但这是一个有趣的问题!
  • 看到各种各样的回复,比如“它绝对是 < there/not-there/some-other-user-table-case > ,而你只是没有做对”,这让人格外沮丧。)
  • 那张桌子没有出现在“展示桌”上
  • 该表是(一直是/曾经是)一个 INNODB 表。
  • 试图 放下表给出的错误消息表不存在。
  • 但是试图 创造表给出的错误消息表已经存在。
  • 使用 mysql 5.0或5.1
  • REPAIR 对此问题无效

This is an old question but I just hit the same issue and 一个答案 in one of the related issues linked at the top was just what I needed and far less drastic than deleting files, tables, shutting down the server etc.

mysqladmin -uxxxxxx -pyyyyy flush-tables