MySQL >表不存在。但它确实(或者应该)
我更改了 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(30)
以防万一有人仍然关心:
使用命令直接复制数据库目录后我遇到了同样的问题
如果你对使用
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
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
andib_logfile1
).When I copied those it worked for me.
对于 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.
当我使用的表名大小写关闭时,我会遇到此问题。所以表被称为“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.
将
lower_case_table_names
设置为1
,然后尝试访问使用该变量的默认值创建的表时,也可能会发生此错误。在这种情况下,您可以将其恢复为之前的值,并且您将能够读取该表。This error can also occur when setting
lower_case_table_names
to1
, 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.我不知道原因,但就我而言,我解决了仅禁用和启用外键检查
I don't know the reason but in my case I solved just disabling and enabling the foreign keys check
cp -a /var/lib/mysql /var/lib/mysql-backup
/var/lib/mysql
mysqldump >dbase.mysql
/var/lib/mysql
/var/lib/mysql-backup
到/var/lib/mysql
mysqldump
数据库.mysql
cp -a /var/lib/mysql /var/lib/mysql-backup
/var/lib/mysql
mysqldump >dbase.mysql
/var/lib/mysql
/var/lib/mysql-backup
to/var/lib/mysql
mysqldump < dbase.mysql
请运行查询:
不幸的是,MySQL 允许在表名中使用 unicode 和不可打印的字符。
如果您通过从某些文档/网站复制创建代码来创建表格,则它有可能在某处具有零宽度空间。
Please run the query:
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.
我也遇到了同样的问题,我搜索了2-3天,但解决方案对我来说真的很愚蠢。
$ sudo service mysql restart
现在表就可以访问了。
I had the same problem and I searched for 2-3 days, but the solution for me was really stupid.
$ sudo service mysql restart
Now tables become accessible.
我刚刚在这个噩梦中度过了三天。理想情况下,您应该有一个可以恢复的备份,然后只需删除损坏的表即可。这些类型的错误可能会导致您的 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.在复制 idb-file 之前尝试运行 sql 查询以丢弃表空间:
复制 idb-file
重新启动 MySql
Try to run sql query to discard tablespace before copying idb-file:
Copy idb-file
Restart MySql
对我有用的就是删除桌子,即使它不存在。然后我重新创建了表并从之前完成的 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.
好吧,这听起来很荒谬,但请幽默一下。
对我来说,当我将声明更改为以下内容时,问题得到了解决:
我做了两个更改
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 :
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.
我在升级WAMP后遇到这个问题,但没有数据库备份。
这对我有用:
停止新的 WAMP
复制您需要的数据库目录和旧 WAMP 安装中的 ibdata1 文件
删除
ib_logfile0
和ib_logfile1
启动 WAMP
您现在应该能够备份数据库。但是,服务器再次重新启动后,您仍然会遇到问题。现在重新安装 WAMP 并导入数据库。
I had this problem after upgrading WAMP but having no database backup.
This worked for me:
Stop new WAMP
Copy over database directories you need and ibdata1 file from old WAMP installation
Delete
ib_logfile0
andib_logfile1
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.
必须重新安装 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.
幽灵表也有类似的问题。值得庆幸的是,在失败之前有一个 SQL 转储。
就我而言,我必须:
/var/mysql
移至备份/var/mysql/{dbname}
注意:需要转储文件。
Had a similar problem with a ghost table. Thankfully had an SQL dump from before the failure.
In my case, I had to:
/var/mysql
off to a backup/var/mysql/{dbname}
NOTE: Requires dump file.
对数据库执行 mysqldump:
恢复数据库
现在数据库中的所有表都已完全恢复。尝试..
Do mysqldump to database:
Restore database
Now all tables in database were restored completely. Try..
看来这个问题与无效(损坏?)innodb 日志文件有关(至少在我的和其他一些人中)。一般来说,它们只需要重新创建即可。
以下是解决方案,大部分需要重启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.
这是另一个场景(版本升级):
我重新安装了我的操作系统(Mac OS El Captain)并安装了新版本的mysql(使用自制程序)。安装的版本(5.7)恰好比我之前的版本新。然后我复制了表,包括 ib* 文件,并重新启动了服务器。我可以在 mysql 工作台中看到表,但是当我尝试选择任何内容时,我得到“表不存在”。
解决方案:
mysql.server stop
或brew services stop mysql
mysqld_safe --user=mysql --datadir=/usr/启动服务器local/var/mysql/
(根据需要更改路径)mysql_upgrade -u root -p password
(在另一个终端窗口中)mysqladmin -u root - p 密码 shutdown
mysql.server start
或brew 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:
mysql.server stop
orbrew services stop mysql
mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/
(change path as needed)mysql_upgrade -u root -p password
(in another terminal window)mysqladmin -u root -p password shutdown
mysql.server start
orbrew services start mysql
Relevant docs are here.
就我而言,我在表上定义了一个触发器,然后尝试在表中插入行。似乎,不知何故触发器是错误的,因此插入给出错误,表不存在。
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.
仅从旧数据目录复制
ibdata1
文件。请勿复制ib_logfile1
或ib_logfile0
文件。这将导致 MySQL 不再启动。Copy only
ibdata1
file from your old data directory. Do not copyib_logfile1
orib_logfile0
files. That will cause MySQL to not start anymore.今天遇到同样的问题。这是一个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.感谢 Alexey Vazhnov 的评论,以下内容对我有用。我运行了这个:
它恢复了我损坏的表
。The following worked for me, thanks to Alexey Vazhnov's comment. I ran this:
And it restored my corrupted table
<tableName>
.您的表名称中可能有隐藏字符。当你做展示表时这些不会出现。您可以执行“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.
我在新计算机上安装了 MariaDB,
停止Mysql服务
将数据文件夹重命名为 data-
我刚刚解决了复制问题
Mysql\data\table_folders 和 ibdata1
从崩溃的 HD MySql 数据文件夹到新安装的 mysql 数据文件夹。
我跳过了ib_logfile0和ib_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.
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.
我认为值得在这里提出的另一个答案(因为我来到这里遇到了同样的问题,这对我来说就是答案):
仔细检查查询中的表名称拼写是否完全相同
有点明显,新手的事情,但像“用户”与“用户”之类的东西可能会让人们绊倒,我认为将其放在此处的列表中将是一个有用的答案。 :)
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. :)
就我而言,当我导入导出的 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.
就我而言,我没有进行数据目录重定位或任何类型的文件操作。事情刚刚发生在一个晴朗的早晨。
奇怪的是,因为我能够使用 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.
我的表格不知何故被重命名为
'Customers'
,即带有前导空格这意味着
a)查询中断
b)表格没有按字母顺序出现在预期的位置我的桌子,在我恐慌中这意味着我看不到它!
My table had somehow been renamed to
' Customers'
i.e. with a leading spaceThis 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!
就我而言,它是 SQLCA.DBParm 参数。
我使用过,
但它必须是
解释:
您将组合三个字符串:
不要在四分号中使用空格。
感谢我的同事简。
In my case it was
SQLCA.DBParm
parameter.I used
but it must be
Explaination :
You are going to combine three strings :
Don't use spaces in quatermarks.
Thank to my colleague Jan.