MySQL >表不存在。但它确实(或者应该)

发布于 2024-12-09 17:41:33 字数 745 浏览 0 评论 0原文

我更改了 MySQL 安装的数据目录,除了一个之外,所有库都正确移动。 我可以连接并使用数据库。 SHOW TABLES 也正确返回所有表,并且每个表的文件都存在于 MySQL 数据目录中。

但是,当我尝试从表中SELECT 某些内容时,我收到一条错误消息,表明该表不存在。然而,这没有意义,因为我能够通过 SHOW TABLES 语句显示同一个表。

我的猜测是 SHOW TABLES 列出文件存在但不检查文件是否损坏。因此,我可以列出这些文件,但不能访问它们。

然而,这只是一个猜测。我以前从未见过这个。现在,我无法重新启动数据库进行测试,但使用它的所有其他应用程序都运行良好。 但这只是猜测,我以前从未见过这种情况。

有谁知道为什么会发生这种情况?

例子:

mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database    |
+-----------------------+
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

I changed the datadir of a MySQL installation and all the bases moved correctly except for one.
I can connect and USE the database. SHOW TABLES also returns me all the tables correctly, and the files of each table exists on the MySQL data directory.

However, when I try to SELECT something from the table, I get an error message that the table does not exist. Yet, this does not make sense since I was able to show the same table through SHOW TABLES statement.

My guess is that SHOW TABLES lists file existence but does not check whether a file is corrupted or not. Consequently, I can list those files but not access them.

Nevertheless, it is merely a guess. I have never seen this before. Now, I cannot restart the database for testing, but every other application that uses it is running fine.
But that's just a guess, I've never seen this before.

Does anyone know why this is happening?

Example:

mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database    |
+-----------------------+
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(30

起风了 2024-12-16 17:41:33

以防万一有人仍然关心:

使用命令直接复制数据库目录后我遇到了同样的问题

cp -r /path/to/my/database /var/lib/mysql/new_database

如果你对使用 InnoDB 表的数据库执行此操作,你会得到这个疯狂的“表不存在”上面提到的错误。

问题是您需要 MySQL 数据目录根目录中的 ib* 文件(例如 ibdata1、ib_logfile0 和 ib_logfile1)代码>)。

当我复制这些时,它对我有用。

Just in case anyone still cares:

I had the same issue after copying a database directory directly using command

cp -r /path/to/my/database /var/lib/mysql/new_database

If you do this with a database that uses InnoDB tables, you will get this crazy 'table does not exist' error mentioned above.

The issue is that you need the ib* files in the root of the MySQL datadir (e.g. ibdata1, ib_logfile0 and ib_logfile1).

When I copied those it worked for me.

屋顶上的小猫咪 2024-12-16 17:41:33

对于 Mac OS 上的我来说(MySQL DMG 安装),只需重新启动 MySQL 服务器即可解决问题。我猜是冬眠造成的。

For me on Mac OS (MySQL DMG Installation) a simple restart of the MySQL server solved the problem. I am guessing the hibernation caused it.

◇流星雨 2024-12-16 17:41:33

当我使用的表名大小写关闭时,我会遇到此问题。所以表被称为“db”,但我在 select 语句中使用了“DB”。确保情况相同。

I get this issue when the case for the table name I'm using is off. So table is called 'db' but I used 'DB' in select statement. Make sure the case is the same.

叫思念不要吵 2024-12-16 17:41:33

lower_case_table_names 设置为 1,然后尝试访问使用该变量的默认值创建的表时,也可能会发生此错误。在这种情况下,您可以将其恢复为之前的值,并且您将能够读取该表。

This error can also occur when setting lower_case_table_names to 1, and then trying to access tables that were created with the default value for that variable. In that case you can revert it to the previous value and you will be able to read the table.

撑一把青伞 2024-12-16 17:41:33

我不知道原因,但就我而言,我解决了仅禁用和启用外键检查

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

I don't know the reason but in my case I solved just disabling and enabling the foreign keys check

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
很糊涂小朋友 2024-12-16 17:41:33
  1. 停止mysqld
  2. 备份mysql文件夹:cp -a /var/lib/mysql /var/lib/mysql-backup
  3. 将数据库文件夹从旧机器复制到/var/lib/mysql
  4. 从旧数据库覆盖 ib* (ib_logfile* , ibdata )
  5. 启动 mysqld
  6. dump dabase
  7. mysqldump >dbase.mysql
  8. 停止 mysql 服务
  9. 删除 /var/lib/mysql
  10. 重命名/var/lib/mysql-backup/var/lib/mysql
  11. 启动 mysqld
  12. 创建数据库
  13. mysqldump 数据库.mysql
  1. stop mysqld
  2. backup mysql folder: cp -a /var/lib/mysql /var/lib/mysql-backup
  3. copy database folder from old machine to /var/lib/mysql
  4. override ib* (ib_logfile* , ibdata ) from old database
  5. start mysqld
  6. dump dabase
  7. mysqldump >dbase.mysql
  8. stop mysql service
  9. remove /var/lib/mysql
  10. rename /var/lib/mysql-backup to /var/lib/mysql
  11. start mysqld
  12. create the database
  13. mysqldump < dbase.mysql
憧憬巴黎街头的黎明 2024-12-16 17:41:33

请运行查询:

SELECT 
    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+

不幸的是,MySQL 允许在表名中使用 unicode 和不可打印的字符。
如果您通过从某些文档/网站复制创建代码来创建表格,则它有可能在某处具有零宽度空间。

,'YES','NO') AS table_name_is_ascii FROM information_schema.`TABLES` i WHERE i.TABLE_SCHEMA = 'database'

不幸的是,MySQL 允许在表名中使用 unicode 和不可打印的字符。
如果您通过从某些文档/网站复制创建代码来创建表格,则它有可能在某处具有零宽度空间。

Please run the query:

SELECT 
    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+

Unfortunately MySQL allows unicode and non-printable characters to be used in table name.
If you created your tables by copying create code from some document/website, there is a chance that it has zero-width-space somewhere.

,'YES','NO') AS table_name_is_ascii FROM information_schema.`TABLES` i WHERE i.TABLE_SCHEMA = 'database'

Unfortunately MySQL allows unicode and non-printable characters to be used in table name.
If you created your tables by copying create code from some document/website, there is a chance that it has zero-width-space somewhere.

好多鱼好多余 2024-12-16 17:41:33

我也遇到了同样的问题,我搜索了2-3天,但解决方案对我来说真的很愚蠢。

重启mysql

$ sudo service mysql restart

现在表就可以访问了。

I had the same problem and I searched for 2-3 days, but the solution for me was really stupid.

Restart the mysql

$ sudo service mysql restart

Now tables become accessible.

眉黛浅 2024-12-16 17:41:33

我刚刚在这个噩梦中度过了三天。理想情况下,您应该有一个可以恢复的备份,然后只需删除损坏的表即可。这些类型的错误可能会导致您的 ibdata1 增长巨大(普通表的大小为 100GB 以上)

如果您没有最近的备份,例如如果您依赖 mySqlDump,那么您的备份可能会悄无声息地损坏在过去的某个时刻。您将需要导出数据库,当然您不能这样做,因为在运行 mySqlDump 时您会遇到锁定错误。

因此,作为解决方法,请转到 /var/log/mysql/database_name/ 并删除 table_name.*

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

在我们的例子中,我们还在所有数据库上以随机间隔不断收到 mysql has gone away 消息;一旦损坏的数据库被删除,一切就恢复正常。

I have just spend three days on this nightmare. Ideally, you should have a backup that you can restore, then simply drop the damaged table. These sorts of errors can cause your ibdata1 to grow huge (100GB+ in size for modest tables)

If you don't have a recent backup, such as if you relied on mySqlDump, then your backups probably silently broke at some point in the past. You will need to export the databases, which of course you cant do, because you will get lock errors while running mySqlDump.

So, as a workaround, go to /var/log/mysql/database_name/ and remove the table_name.*

Then immediately try to dump the table; doing this should now work. Now restore the database to a new database and rebuild the missing table(s). Then dump the broken database.

In our case we were also constantly getting mysql has gone away messages at random intervals on all databases; once the damaged database were removed everything went back to normal.

清醇 2024-12-16 17:41:33

在复制 idb-file 之前尝试运行 sql 查询以丢弃表空间:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

复制 idb-file

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

重新启动 MySql

Try to run sql query to discard tablespace before copying idb-file:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Copy idb-file

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Restart MySql

千寻… 2024-12-16 17:41:33

对我有用的就是删除桌子,即使它不存在。然后我重新创建了表并从之前完成的 sql 转储中重新填充。

一定有一些表名的元数据库,并且它很可能仍然存在于其中,直到我删除它。

What worked for me, was just dropping the table, even though it didnt exist. Then I re created the table and repopulated from an sql dump done previously.

There must be some metabase of table names, and it was most likely still existing in there till i dropped it.

别理我 2024-12-16 17:41:33

好吧,这听起来很荒谬,但请幽默一下。
对我来说,当我将声明更改为以下内容时,问题得到了解决:

SELECT * FROM `table`

我做了两个更改
1.) 将表名设为小写 - 我知道!!
2.) 使用特定的引号 = ` :这是 TAB 上方的键

该解决方案听起来确实很荒谬,但它有效,而且是周六晚上,我从上午 9 点就开始工作 - 所以我'我会接受的:)

祝你好运。

O.k. this is going to sound pretty absurd, but humor me.
For me the problem got resolved when I changed my statement to this :

SELECT * FROM `table`

I made two changes
1.) Made the table name lower case - I know !!
2.) Used the specific quote symbol = ` : It's the key above your TAB

The solution does sound absurd, but it worked and it's Saturday evening and I've been working since 9 a.m. - So I'll take it :)

Good luck.

眼眸印温柔 2024-12-16 17:41:33

我在升级WAMP后遇到这个问题,但没有数据库备份。

这对我有用:

  1. 停止新的 WAMP

  2. 复制您需要的数据库目录和旧 WAMP 安装中的 ibdata1 文件

  3. 删除ib_logfile0ib_logfile1

  4. 启动 WAMP

您现在应该能够备份数据库。但是,服务器再次重新启动后,您仍然会遇到问题。现在重新安装 WAMP 并导入数据库。

I had this problem after upgrading WAMP but having no database backup.

This worked for me:

  1. Stop new WAMP

  2. Copy over database directories you need and ibdata1 file from old WAMP installation

  3. Delete ib_logfile0 and ib_logfile1

  4. Start WAMP

You should now be able to make backups of your databases. However after your server restarts again you will still have problems. So now reinstall WAMP and import your databases.

后eg是否自 2024-12-16 17:41:33

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

After having to reinstall MySQL I had this same problem, it seems that during the install, some configuration files that store data about the InnoDB log files, these files ib_logfile* (they are log files right?), are overwriten. To solve this problem I just deleted the ib_logfile* files.

风尘浪孓 2024-12-16 17:41:33

幽灵表也有类似的问题。值得庆幸的是,在失败之前有一个 SQL 转储。

就我而言,我必须:

  1. 停止 mySQL
  2. 将 ib* 文件从 /var/mysql 移至备份
  3. 删除 /var/mysql/{dbname}
  4. 重新启动 mySQL
  5. 重新创建空数据库
  6. 恢复转储文件

注意:需要转储文件。

Had a similar problem with a ghost table. Thankfully had an SQL dump from before the failure.

In my case, I had to:

  1. Stop mySQL
  2. Move ib* files from /var/mysql off to a backup
  3. Delete /var/mysql/{dbname}
  4. Restart mySQL
  5. Recreate empty database
  6. Restore dump file

NOTE: Requires dump file.

简单爱 2024-12-16 17:41:33
  1. 对数据库执行 mysqldump:

    mysqldump -u user -ppass dbname > D:\Backups\dbname.sql
    
  2. 恢复数据库

    mysql -u user -ppass dbname mysql -u user -ppass dbname < D:\Backups\dbname.sql
    

现在数据库中的所有表都已完全恢复。尝试..

SELECT * FROM dbname.tablename;
  1. Do mysqldump to database:

    mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
    
  2. Restore database

    mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
    

Now all tables in database were restored completely. Try..

SELECT * FROM dbname.tablename;
固执像三岁 2024-12-16 17:41:33

看来这个问题与无效(损坏?)innodb 日志文件有关(至少在我的和其他一些人中)。一般来说,它们只需要重新创建即可。

以下是解决方案,大部分需要重启mysql。

  • 重新创建日志文件(删除并重新启动mysql)
  • 调整日志大小文件(MySql 5.6+ 将为您重新生成文件)
  • 如果您正在进行某种类型的数据迁移,请确保您已正确迁移正确的文件并为其授予权限,正如其他人已经说明的那样
  • 检查数据的权限和日志文件,mysql 是两者的所有者
  • 如果所有其他方法都失败,您可能必须重新创建数据库

It appears that the issue has to do (at least in mine and a few others) with invalid (corrupt?) innodb log files. Generally speaking, they simply need to be recreated.

Here are solutions, most of which require a restart of mysql.

  • Recreate your log files (Delete and restart mysql)
  • Resize your log files (MySql 5.6+ will regenerate the file for you)
  • If you are doing some type of a data migration, make sure you have correctly migrated the right file and given it permissions as others have already stated
  • Check permissions of your data and log files, that mysql is owner of both
  • If all else fails, you will likely have to recreate the database
违心° 2024-12-16 17:41:33

这是另一个场景(版本升级)

我重新安装了我的操作系统(Mac OS El Captain)并安装了新版本的mysql(使用自制程序)。安装的版本(5.7)恰好比我之前的版本新。然后我复制了表,包括 ib* 文件,并重新启动了服务器。我可以在 mysql 工作台中看到表,但是当我尝试选择任何内容时,我得到“表不存在”。

解决方案:

  1. 停止mysql服务器,例如mysql.server stopbrew services stop mysql
  2. 使用mysqld_safe --user=mysql --datadir=/usr/启动服务器local/var/mysql/(根据需要更改路径)
  3. 运行mysql_upgrade -u root -p password(在另一个终端窗口中)
  4. 关闭正在运行的服务器mysqladmin -u root - p 密码 shutdown
  5. 以正常模式重启服务器mysql.server startbrew services start mysql

相关文档为 此处

Here is another scenario (version upgrade):

I reinstalled my OS (Mac OS El Captain) and installed a new version of mysql (using homebrew). The installed version (5.7) happened to be newer than my previous one. Then I copied over the tables, including the ib* files, and restarted the server. I could see the tables in mysql workbench but when I tried to select anything, I got "Table doesn't exist".

Solution:

  1. stop the mysql server e.g. mysql.server stop or brew services stop mysql
  2. start the server using mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (change path as needed)
  3. run mysql_upgrade -u root -p password (in another terminal window)
  4. shut down the running server mysqladmin -u root -p password shutdown
  5. restart the server in normal mode mysql.server start or brew services start mysql

Relevant docs are here.

简单气质女生网名 2024-12-16 17:41:33

就我而言,我在表上定义了一个触发器,然后尝试在表中插入行。似乎,不知何故触发器是错误的,因此插入给出错误,表不存在。

In my case, i had defined a trigger on the table and then was trying to insert the row in table. seems like, somehow trigger was erroneous, and hence insert was giving error, table doesn't exist.

违心° 2024-12-16 17:41:33

仅从旧数据目录复制 ibdata1 文件。请勿复制 ib_logfile1ib_logfile0 文件。这将导致 MySQL 不再启动。

Copy only ibdata1 file from your old data directory. Do not copy ib_logfile1 or ib_logfile0 files. That will cause MySQL to not start anymore.

葵雨 2024-12-16 17:41:33

今天遇到同样的问题。这是一个mysql“标识符大小写敏感”问题。

请检查相应的数据文件。文件系统上的文件名很可能是小写的,但“showtables”命令中列出的表名是大写的。如果系统变量“lower_case_table_names”为 0,则查询将返回“表不存在”,因为当“lower_case_table_names”为 0 时,名称比较区分大小写。

Came cross same problem today. This is a mysql "Identifier Case Sensitivity" issue.

Please check corresponding data file. It is very likely that file name is in lower case on file system but table name listed in "show tables" command is in upper case. If system variable "lower_case_table_names" is 0, the query will return "table not exist" because name comparisons are case sensitive when "lower_case_table_names" is 0.

无可置疑 2024-12-16 17:41:33

感谢 Alexey Vazhnov 的评论,以下内容对我有用。我运行了这个:

SET FOREIGN_KEY_CHECKS=0;
SHOW CREATE TABLE <tableName>;
SET FOREIGN_KEY_CHECKS=1;

它恢复了我损坏的表

The following worked for me, thanks to Alexey Vazhnov's comment. I ran this:

SET FOREIGN_KEY_CHECKS=0;
SHOW CREATE TABLE <tableName>;
SET FOREIGN_KEY_CHECKS=1;

And it restored my corrupted table <tableName>.

哥,最终变帅啦 2024-12-16 17:41:33

您的表名称中可能有隐藏字符。当你做展示表时这些不会出现。您可以执行“SHOW CREATE TABLE TABLE_ONE”并按 Tab 完成“TABLE_ONE”并查看它是否放入任何隐藏字符。另外,您是否尝试过丢弃并重新制作桌子。只是为了确保权限没有问题并且没有隐藏的角色。

Its possible you have a hidden character in your table name. Those don't show up when you do a show tables. Can you do a "SHOW CREATE TABLE TABLE_ONE" and tab complete the "TABLE_ONE" and see if it puts in any hidden characters. Also, have you tried dropping and remaking the tables. Just to make sure nothing is wrong with the privileges and that there are no hidden characters.

隐诗 2024-12-16 17:41:33

我在新计算机上安装了 MariaDB,
停止Mysql服务
将数据文件夹重命名为 data-
我刚刚解决了复制问题
Mysql\data\table_foldersibdata1
从崩溃的 HD MySql 数据文件夹到新安装的 mysql 数据文件夹。

我跳过了ib_logfile0ib_logfile1(否则服务器没有启动服务)

启动了mysql服务。

然后服务器正在运行。

I installed MariaDB on new computer,
stopped Mysql service
renamed data folder to data-
I solved my problem copying just
Mysql\data\table_folders and ibdata1
from crashed HD MySql data Folder to the new installed mysql data folder.

I Skipped ib_logfile0 and ib_logfile1 (otherwise the server did not start service)

Started mysql service.

Then server is running.

盛夏尉蓝 2024-12-16 17:41:33

TimeMachine 备份导入后出现同样的问题。我的解决方案是停止 MySQL 服务器并修复 ib* 文件的读写权限。

Same exact problem after TimeMachine backup import. My solution was to stop the MySQL server and fix read-write permissions on the ib* files.

短叹 2024-12-16 17:41:33

我认为值得在这里提出的另一个答案(因为我来到这里遇到了同样的问题,这对我来说就是答案):

仔细检查查询中的表名称拼写是否完全相同

有点明显,新手的事情,但像“用户”与“用户”之类的东西可能会让人们绊倒,我认为将其放在此处的列表中将是一个有用的答案。 :)

One other answer I think is worth bringing up here (because I came here with that same problem and this turned out to be the answer for me):

Double check that the table name in your query is spelled exactly the same as it is in the database.

Kind of an obvious, newbie thing, but things like "user" vs "users" can trip people up and I thought it would be a helpful answer to have in the list here. :)

童话 2024-12-16 17:41:33

就我而言,当我导入导出的 sql 文件时,我收到一条错误,例如创建表查询的表不存在。

我意识到我的数据库名称中有一个下划线,并且 mysql 在其前面放置了一个转义字符。

所以我删除了数据库名称中的下划线,一切顺利。

希望它也对其他人有帮助。

In my case, when I was importing the exported sql file, I was getting an error like table doesn't exist for the create table query.

I realized that there was an underscore in my database name and mysql was putting an escape character just before that.

So I removed that underscore in the database name, everything worked out.

Hope it helps someone else too.

遗弃M 2024-12-16 17:41:33

就我而言,我没有进行数据目录重定位或任何类型的文件操作。事情刚刚发生在一个晴朗的早晨。

奇怪的是,因为我能够使用 mysqldump 转储表,尽管 MySQL 有时会抱怨“表不存在”,但我通过转储表的架构 + 数据来解决它,然后 DROP-ing 表,然后重新之后立即创建它,然后导入。

In my case, I had that without doing a datadir relocation or any kind of file manipulation. It just happened one fine morning.

Since, curiously, I was able to dump the table, using mysqldump, despite MySQL was sometimes complaining about "table does not exist", I resolved it by dumping the schema + data of the table, then DROP-ing the table, and re CREATE it immediately after, followed by an import.

源来凯始玺欢你 2024-12-16 17:41:33

我的表格不知何故被重命名为'Customers',即带有前导空格

这意味着

a)查询中断

b)表格没有按字母顺序出现在预期的位置我的桌子,在我恐慌中这意味着我看不到它!

RENAME TABLE ` Customer` TO `Customer`;

My table had somehow been renamed to ' Customers' i.e. with a leading space

This meant

a) queries broke

b) the table didn't appear where expected in the alphabetical order of my tables, which in my panic meant I couldn't see it!

RENAME TABLE ` Customer` TO `Customer`;
冰魂雪魄 2024-12-16 17:41:33

就我而言,它是 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)

不要在四分号中使用空格。
感谢我的同事简。

In my case it was SQLCA.DBParm parameter.

I used

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

but it must be

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

Explaination :

You are going to combine three strings :

 1. Database='              -  "Database='"

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

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

Don't use spaces in quatermarks.
Thank to my colleague Jan.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文