错误：表xxx的表空间已存在。请在导入之前丢弃表空间

我是MySQL的新手，但遇到一个非常有趣的错误，我无法通过Google和stackoverflow搜索找到任何帮助。

我在MacOS 10.8.3上运行MySQL 5.6.10的本地服务器，并通过Navicat Essentials for MySQL管理数据库。

我得到的错误是，在运行和管理数据库几天/几周后，某些触发器触发了（它看起来不完整）删除了一些我使用Navicat中的查询创建的表。

当我尝试使用这些表运行查询时，Navicat随后警告我该特定表不存在。到目前为止，一切都很好-这里有很多好处：

当我尝试创建表（例如以前称为“ temp”）时，会收到以下错误消息：

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

但是，如果我尝试删除该表或尝试放弃该表的表空间，请使用

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

我收到以下错误消息：

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

因此，这意味着建议我放弃表空间，但是当我尝试这样做时，该表不存在。是否可能在不检查DISCARD查询的其他位置存在此表的某种剩余形式？有人知道什么可以触发所有这些吗？看起来是完全随机的吗？

正如我所说，我是这个主题的新手，几乎毫无头绪。我怀疑重新启动我的笔记本电脑，即重置我的本地MySQL服务器，或者可能与用户权限有关，但是我只是在这里假设。

在这里稍晚一些，但通常我已经看到在“ innodb_file_per_table”模式下运行时遇到“表空间已满”错误时会发生此问题。无需赘述（更多信息），数据库服务器的表空间由innodb_data_file_path设置定义，默认情况下很小。即使变大，“表空间已满”仍然会在更大的查询中发生（诸如大量非表“材料”存储在此处，撤消日志，缓存等）。

无论如何，我发现如果您查看存储每张表文件的OS目录，默认情况下在OSX上使用/ var / lib / mysql，使用自制软件iirc在/ usr / local / var / mysql上查找，孤立的tablename.ibd文件，但没有普通的伴随tablename.frm文件。如果将该.ibd文件移动到安全的临时位置（为了安全起见），则应该可以解决此问题。

$ ls /var/lib/mysql

table1.frm
table1.idb
table2.frm
table2.ibd
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb

$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/

请注意，请确保最初导致问题的原因已清除，例如长时间运行的查询，锁定的表等。否则，当您再次尝试时，最终只会得到另一个孤立的.ibd文件。

Xampp和Mamp用户

通过MySQL导入数据库（清空数据库后）时发生了相同的错误。我发现tablename.ibd剩下的所有其他文件都被删除了。我手动mysql/data/database_name将其删除，错误消失了。

对于WAMP [Windows 7 Ultimate x64位]用户：

我同意DangerDave所说的，所以我正在为WAMP用户提供答案。

注意：首先，您必须转到.. \ WAMP \ Bin \ MySQL \ MySQL [您的MySQL版本] \ Data文件夹。

现在，您将看到所有数据库的文件夹

• 双击包含有问题表的数据库文件夹以将其打开
• 不应有文件[Your offending MySQL table name].frm，而应有文件[Your offending MySQL table name].ibd
• 删除 [Your offending MySQL table name].ibd
• 然后，也将其从回收站中删除
• 然后在数据库上运行MySQL查询，操作完成

如果.idb删除后再次得到重新创建的内容，请阅读此答案。

这就是我的工作方式。我有.idb没有相应文件的文件，每.frm删除该.idb文件，数据库都会重新创建它。并且我在MySQL 文档的一行中找到了解决方案（“ 表空间不存在”部分）

1-在其他数据库目录中创建匹配的.frm文件，并将其复制到孤立表所在的数据库目录中。

2-发出原始表的DROP TABLE。那应该成功删除该表，并且InnoDB应该在错误日志中显示一个警告，指出.ibd文件丢失。

我复制了另一个表.frm文件，并像丢失的表一样命名它，然后进行普通的删除表查询，瞧，它起作用了，并且该表正常删除了！

我的系统是Windows MariaDB v 10.1.8上的XAMPP

就我而言，唯一的工作解决方案是：

1. 创建表bad_table引擎= MyISAM ...
2. rm bad_table.ibd
3. 滴台 bad_table

当我有一个表在日志文件中显示完全相同的错误时，这正是我在fedora的mariadb 10.2.16中所做的...

2018-07-11  9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11  9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918

您的里程和错误可能会有所不同，但我认为主要是

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

与删除表不起作用以及更改表...

MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'

MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist

创建表也将失败，如下所示：

MariaDB [database_name]> create table  innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT

为了解决这个问题，我首先要做的是

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

然后在/ var / lib / mysql / database_name目录中，我以root身份执行以下操作，以确认innodb_table.ibd的覆盖导致了我们的问题

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

然后回到mysql控制台，我在两个表上都发出了成功的drop命令

MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: database_name

Query OK, 0 rows affected (0.08 sec)

MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)

现在一切都变成正方形了，我可以重新创建一张桌子...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

编辑：我要添加一个

restorecon -Rv /var/lib/mysql/database_name 

复制数据库后的命令以按其应有的方式获取所有selinux上下文，即使我们几乎立即将它们从数据库中删除，但也可以将--archive或-a选项添加到两个cp中命令，所以实际上是archive选项可以缩短此操作：

cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

我认为更好的是以下内容，它保留为已制成的表设置的selinux上下文。

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

我已将上述较长的命令列表替换为较短的命令列表，可以将其缩短为*

就我而言：

首先tableName.ibd从Mysql中删除数据库目录，然后再次运行：

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

尝试创建用户表时，在wampserver上运行该错误。我找到了一个users.ibd文件，删除该文件后，我再次运行migration命令，它开始工作。我的Windows机器上的文件位于wamp / bin / mysql / mysql5.6.12 / data / myproject中。

解

但是，更简单的选择是：重新启动MySQL，然后执行以下四个相同的步骤：

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

这样，数据字典上的表空间ID与文件匹配；这样就成功导入了表空间。

这可以使您更有信心在恢复过程甚至文件传输过程中处理InnoDB的“陷阱”。

参考

这是解决方法步骤：

1. 备份数据库（带有删除选项和数据的结构）
2. 停止mysql引擎服务
3. 从mysql / data内部手动删除数据库目录
4. 启动mysql引擎
5. 使用与损坏的数据库不同的名称创建新数据库
6. 在新数据库中创建具有损坏表名称的单个表（这是秘密）。并且最好使用完全相同的结构创建表。
7. 将数据库重命名为旧的损坏的数据库
8. 恢复您的备份，您的表将正常工作。

曾多次发生此问题。如果您的数据库很大，并且想避免进行备份/还原（添加了丢失的表），请来回尝试几次：

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-和-

位于/ var / lib / mysql / my_db /目录中的rm my_table.ibd（无对应的my_table.frm孤儿）

-然后-

如果不存在则创建表my_table（...）

删除/移动tablename.ibd肯定对我不起作用。

我是怎么解决的

由于我要删除已损坏且不存在的表，因此我通过将其他表备份到phpmyadmin-> database-> export-> selected表到backup-> export（如.sql）来进行备份。

之后，我选择了数据库名称旁边的数据库图标，然后将其删除。创建一个新的数据库。选择新数据库->导入->选择先前下载的文件->单击导入。现在，我有了旧的工作表，并删除了损坏的表。现在，我只创建引发错误的表。

可能我有损坏表的较早备份。

当您暂停某些功能时，会发生此错误。就像使用错误的外键运行以下查询一样。

set foreign_key_checks=0

有完全一样的问题；我会冲泡添加mysql@5.6（之前为5.5）。

brew默认值是5.6，innodb_file_per_table=1而5.5是innodb_file_per_table=0。

您现有的ibdata1文件（合并的innodb数据）仍将包含您要创建/删除的表的引用。改innodb_file_per_table回0或删除ibdata1数据文件（这将丢失所有数据，因此请确保首先对它进行mysqldump或已经具有.sql dump）。

mysql@5.6困扰我的另一个brew 默认是缺少端口，因此网络默认为unix套接字，并且mysql客户端不断报告：

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

我已添加<string>--port=3306</string>到.plist数组，但您也可以port=3306在my.cnf

brew services stop mysql@5.6然后运行进行更改brew services start mysql@5.6

尝试删除表空间可能会给您其他错误。对我来说，出现以下错误：

DROP TABLESPACE `tablename`

Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' 

我的解决方案是删除数据库。这将删除与其相关的所有表空间，并允许您再次创建表。

如果您的另一台服务器具有相同表的良好版本，则可以进行复制（table_copy），将table_copy转移到问题服务器。然后删除问题表，并将table_copy重命名为table。

对我来说，它只帮助进入/ var / lib / mysql / {db_name}（linux）下的MYSQL DATA目录，并删除与文件夹名称相同的{table_name} .ibd文件。

我仅直接从wamp删除了位于本地主机中的旧数据库，停止了所有服务，转到wamp / bin / mysql / mysql [version] / data，发现该数据库出现问题，我删除了它，然后再次开始对所有服务进行wamp，再次创建数据库并完成，现在可以导入表，

我发现“解决”此问题的方法很烦人，但是有一个脚本可以处理它。

本质上，您需要删除ibdata1和ib_logfile*文件（它们包含外键的映射等）。唯一安全方法是导出所有数据库，停止mysql，删除文件，启动mysql，然后导入文件。

帮助解决此问题的脚本是https://github.com/uberhacker/shrink-ibdata1，即使该脚本的既定目的不同，它也可以解决该问题。

它对我有用的唯一方法是：

1. 创建一个相似的表
2. 将新的相似表的.frm和.idb文件复制到损坏的表的名称。
3. 修复权限
4. 重新启动MariaDB
5. 删除损坏的表

如果您遇到此问题，并且没有其他选择，请将引擎更改为其他任何引擎（例如“ myisam”），然后尝试创建表。

免责声明： 这不是有效答案，因为您可能具有外键约束，而另一个存储引擎将不支持该约束。每个存储引擎都有自己的专业来存储和访问数据，这些要点也要考虑在内。

请在导入之前丢弃表空间

我在下面有相同的问题解决方案

1. 首先，您必须删除数据库名称。如果您的数据库没有删除，您就会流连忘返。对于Windows系统，您的目录将为C：/ xampp / mysql / data / yourdabasefolder删除“ yourdabasefolder”

2. 同样，您必须创建新的数据库并导入旧的sql文件。会的

谢谢

我必须找到我的MySQL数据目录：

在变量名类似“％dir”的位置显示变量

然后强制删除该数据库：

须藤rm -rf

您可以以mysql root用户身份运行以下查询

drop tablespace `tableName`

嘿，开发人员不会浪费您的时间。只需删除包含表的数据库，然后再次导入整个表。节省时间=时间就是金钱。干杯。