当我使用的表名的大小写关闭时，我就会遇到这个问题。所以表被称为'db'但我在select语句中使用'db'。确保箱子是一样的。

我花了三天时间在这个噩梦上。理想情况下，您应该有一个可以恢复的备份，然后只需删除损坏的表。这类错误可能导致ibdata1变大(一般表的大小为100GB以上)。

如果您没有最近的备份，例如如果您依赖mySqlDump，那么您的备份可能在过去的某个时候无声地崩溃了。您将需要导出数据库，当然您不能这样做，因为您将在运行mySqlDump时得到锁定错误。

因此，作为一种变通方法，转到/var/log/mysql/database_name/并删除table_name.*

然后立即尝试转储表;这样做现在应该可以工作了。现在将数据库恢复到一个新的数据库，并重新构建丢失的表。然后转储损坏的数据库。

在我们的例子中，我们还不断地在所有数据库上随机地得到mysql已经离开的消息;一旦损坏的数据库被删除，一切都恢复正常。

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

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

在我的例子中是SQLCA。DBParm参数。

我使用

SQLCA.DBParm = "Databse = "sle_database.text""

但它必须是

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

解释:

你将组合三个字符串:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

不要在四元符号中使用空格。 感谢我的同事Jan。

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

请运行查询:

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和非打印字符。 如果你通过复制一些文档/网站的create代码来创建你的表，那么它可能在某个地方有零宽度空间。