无法改变表，表'xxx /＃sql-ib265'已经存在

Question

我在数据库xxx中有一个mysql表y，我尝试在使用

之前更改压缩类型

    alter table y row_format=compressed key_block_size=8

该过程中途停止了。我在mysql lib目录中删除了临时文件'#sql-ib265.frm和#sql-ib265'并重新启动了服务器。然而 现在，当我再次尝试使用alter table y（使用上面相同的命令）时，我得到了错误。

    ERROR 1050 (42S01) at line 1: Table 'xxx/#sql-ib265' already exists

我无法删除表'xxx /＃sql-ib265'，因为无法找到它。 我该怎么办？

编辑 解决方案：

I ended up dropping the old database and recreate the database.

Answer 1

尝试使用--skip-auto-rehash选项重启mysql客户端，然后再次尝试DROP TABLE。

如果以上操作不起作用，请从MySQL手册中试试：

你有一个腐败的innodb数据字典..

https://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html

临时表问题

如果MySQL在ALTER TABLE操作过程中崩溃，您最终可能会在InnoDB表空间内找到一个孤立的临时表。使用表监视器，您可以看到列出名称以＃sql-开头的表。如果将名称括在反引号中，则可以对名称中包含字符“＃”的表执行SQL语句。因此，您可以使用前面描述的方法删除像任何其他孤立表一样的孤立表。要复制或重命名Unix shell中的文件，如果文件名包含“＃”，则需要将文件名放在双引号中。

Answer 2

有两种方法可以解决这个问题。

1. 正如其他答案所示，official MySQL documentation suggests放下一个特制的桌子。但请注意，在版本＆gt; = 5.1中，您需要在表名前加上#mysql50#。
2. 将所有好的表移动（使用RENAME TO）到临时数据库，删除并重新创建原始表，然后移回表。有关详细信息，请参阅a blog post。

Answer 3

另外，使用root登录以执行恢复作业但失败了。然后我知道.frm文件以满足mysql服务的所有者并成功。

Answer 4

对于仍然面临这个问题的人，我只是按照以下步骤来解决它，这对我来说（至少对我而言）似乎远不如其他解决方案那么令人生畏：

1. 使用mysqldump备份数据库及其所有数据。
2. 删除并重新创建数据库。
3. 从（1）中生成的文件重新加载数据库及其所有架构。

因为无论如何都隐藏了孤立的表，所以它们不会被备份，所以最终会得到一个没有它们的数据库。无论如何我都编写了所有的程序/函数，因此能够轻松地恢复它们 - 如果不这样做，请确保使用--routines参数来转储它们。

对于有问题的数据库，我的转储文件大约为1.5GB（所以它不小），整个过程在几分钟内就完成了。