首页 文章

SchrödingersMySQL表：存在，但它没有

提问于
浏览 次
113

我遇到了最奇怪的错误 .

有时，在创建或更改表时，我会得到“表已存在”错误 . 但是，DROP TABLE返回'＃1051 - unknown table' . 所以我得到了一张我无法创作的 table ，不能放弃 .

当我尝试删除数据库时，mysqld崩溃了 . 有时它有助于创建具有不同名称的另一个数据库，有时它不会 .

我使用一个包含约50个表的数据库，所有数据都是InnoDB . 不同的表发生此问题 .

我在Windows，Fedora和Ubuntu，MySQL 5.1和5.5上经历过这个 . 使用PDO，PHPMyAdmin或命令行时的行为相同 . 我使用MySQL Workbench来管理我的架构 - 我看到了一些相关的错误（背景和内容），但是没有一个与我相关 .

不，这不是一个观点，它是一张 table . 所有名称都是小写的 .

我尝试了所有我可以谷歌 - 冲洗表，将.frm文件从db移动到db，读取mysql日志，没有任何帮助，但重新安装整个该死的东西 .

“显示表格”没有显示任何内容，“描述”表说“表格不存在”，没有.frm文件，但“创建表格”仍然以错误结束（'如果不存在则创建表'）和删除数据库会导致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

名称更改，这不是我遇到问题的唯一表/数据库

mysql

12 回答

  • -1

    我有这个问题，并希望删除IBD文件将有助于上面发布，但它没有任何区别 . MySQL只重新创建了一个新的IBD文件 . 就我而言，在同一MySQL实例中的其他数据库中实际上存在类似的表 . 由于缺少FRM文件，我从另一个数据库中的类似表中复制了FRM文件，重新启动了MySQL并且表格正常工作 .

    回复于
  • 3

    在我的例子中，通过将mysql数据目录的所有权更改为运行应用程序的用户来解决问题 . （在我的例子中，它是一个运行Jetty webserver的Java应用程序 . ）

    即使mysql正在运行而其他应用程序可以正常使用它，这个应用程序也有问题 . 更改数据目录所有权并重置用户密码后，一切正常 .

    回复于
  • 12

    如果将存在此错误1051并且您只想删除数据库并再次导入，请执行此步骤并且一切都会好的....

    在Unix envoriment AS root ：

    • rm -rf /var/lib/mysql/YOUR_DATABASE;

    • 可选 - > mysql_upgrade --force

    • mysqlcheck -uUSER -pPASS YOUR_DATABASE

    • mysqladmin -uUSER -pPASS drop YOUR_DATABASE

    • mysqladmin -uUSER -pPASS create YOUR_DATABASE

    • mysql -uUSER -pPASS YOUR_DATABASE < IMPORT_FILE

    此致，Christus

    回复于
  • 3

    这个问题也可以解决

    DROP TABLE IF EXISTS `tablename` ;
FLUSH TABLES `tablename` ; /* or exclude `tablename` to flush all tables */
CREATE TABLE `tablename` ...
    回复于
  • 0

    修复结果很简单;至少我的工作，为我工作 . 在另一个MySQL实例上创建一个表“zzz”，其中zzz是问题表名 . （即如果该表被称为schrodinger，则将其替换为zzz，无论何时写入 . ）表的定义是什么并不重要 . 这是一个临时假人;将zzz.frm文件复制到该表所在的服务器上的数据库目录中，确保文件的文件所有权和权限仍然正确 . 在MySQL上，你现在可以做“show tables;”，表zzz就在那里 . mysql> drop table zzz; ......现在应该有效 . 如有必要，清除目录中的所有zzz.MYD或ZZZ.MYI文件 .

    回复于
  • 0

    这是一个老问题，但我只是遇到了同样的问题，an answer在顶部链接的一个相关问题正是我所需要的，远不如删除文件，表，关闭服务器等 .

    mysqladmin -uxxxxxx -pyyyyy flush-tables
    回复于
  • 0

    它发生在我们的站点（但很少），通常是在运行某些执行大量重建的脚本时发生"event" . 事件包括网络中断或电源问题 .
    在极少数情况下我会为此做些什么 - 我使用严厉的方法：

    • 我需要简单地摆脱并重建特定的表 . 我通常处于这样的位置，因为 table 正在建造中 . （如果需要恢复数据，您的情况可能会有所不同）

    • 作为管理员，进入mysql安装（在Windows上可能是“...程序文件/ mysql / MySQL服务器xx / data / <schemaname>

    • 在<schemaname>文件夹中找到包含表名的违规文件 - 并将其删除 .

    • 检查孤立的临时文件并删除它们 . ＃... frm文件，如果他们碰巧在那里 .

    • MySQL将让你再次创建表

    我在很长一段时间（几年）的几个不同的数据库上遇到过这个问题 . 这是一个难以接受的因为矛盾的信息 . 我第一次对其他答案中描述的删除/重建/重命名数据库进行了变化，并设法让事情顺利进行，但这肯定需要更长的时间 . 幸运的是，我总是碰巧引用正在重建的表--DROP'd和CREATEd - 通常在早上 . 很少遇到问题，但后来认识到这是一个特殊的古怪案例 . （我会重申一下：如果您需要恢复数据，请查看其他解决方案 . ）

    • 它不是属于另一个用户或另一个数据库的表

    • 这不是大写/小写的问题，我使用全部小写，但这是一个有趣的问题！

    • 这是额外的令人沮丧的看到响应与"it definitely was <there/not-there/some-other-user-table-case> and you're just not doing it right" :)的变化

    • 表没有显示"show tables"

    • 表是（一直是/曾经）一张INNODB表 .

    • 尝试DROP表给出了表不存在的错误消息 .

    • 但尝试创建表时给出了表已存在的错误消息 .

    • 使用mysql 5.0或5.1

    • REPAIR对此问题无效

    回复于
  • -2

    我在一个特定的 table 上遇到了这个问题 . 阅读可能的解决方案我做了一些步骤，如：

    • 搜索孤儿文件：不存在任何人;

    • 执行： show full tables in database; ：没有看到有问题的;

    • 执行： describe table; ：返回 table doesn't exist ;

    • 执行： SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table'; ：返回 Empty set ;

    • 手动搜索phpMyAdmin上面的查询：不存在;

    并且，在这些步骤之后，我再次检查 show tables; 和...vualá！有问题的 table 消失了 . 我可以创建它并使用相同的有问题的名称删除它没有问题，我甚至没有重启服务器！奇怪的...

    回复于
  • 0

    我创建一个表并删除它之后遇到了这个错误，然后想再次创建它 . 在我的例子中，我有一个自包含的转储文件，所以我删除了我的模式，重新创建它并使用转储文件导入表和数据 .

    回复于
  • 3

    我've seen this issue when the data file is missing in the data directory but the table definition file exists or vise-versa. If you'使用innodb_file_per_table，检查数据目录以确保您有相关表的 .frm 文件和.ibd文件 . 如果它是MYISAM，则应该有 .frm ， .MYI 和 .MYD 文件 .

    通常可以通过手动删除孤立文件来解决此问题 .

    回复于
  • 16

    在这里疯狂猜测，但似乎innodb仍然在表空间中有一个表的条目，可能在 ibdata . 如果 really 不需要 any 数据，或者您有备份，请尝试以下操作：

    • 删除所有模式（不包括mysql）

    • 关闭数据库

    • 确保数据目录中的所有文件夹都已正确删除（再次，不包括mysql）

    • 删除ibdata和日志文件

    • 重启数据库 . 它应该从头开始重新创建表空间和日志 .

    回复于
  • 1

    我怀疑这是问题案例的直接答案，但这是我在OS X Lion系统上解决 this exact perceived problem 的方法 .

    我经常为我安排的一些分析工作创建/删除表 . 在某些时候，我开始通过我的脚本中途获取表已经存在的错误 . 服务器重启通常可以解决问题，但这对解决方案来说太烦人了 .

    然后我在本地错误日志文件中注意到这一特定行：

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

    这给了我一个想法，也许如果我的表格包含大写字母，MySQL会被愚弄，以为即使在我放弃它们之后它们仍然存在 . 事实证明是这种情况，并且转换为仅使用小写字母表格名称使问题消失 .

    这可能是我案例中一些配置错误的结果，但希望这个错误案例可以帮助有人浪费更少的时间来寻找解决方案 .

    回复于

相关问题