我正在尝试转储我的数据库:
mysqldump myDatabase > myDatabase.sql
但是我收到了这个错误:
mysqldump: Got error: 1146: Table 'myDatabase.table' doesn't exist when using LOCK TABLES
当我去mysql:
mysql -u admin -p
我查询表格:
show tables;
我看到了桌子。但是当我查询那个特定的表时:
select * from table;
我得到同样的错误:
ERROR 1146 (42S02): Table 'myDatabase.table' doesn't exist
我试图修复:
mysqlcheck -u admin -p --auto-repair --check --all-databases
但得到同样的错误:
Error : Table 'myDatase.table' doesn't exist
为什么我收到此错误或如何解决此错误?
我真的很感谢你的帮助
答案 0 :(得分:2)
我在服务器上执行 mysqldump 时遇到问题,我意识到如果长时间不使用这些表,那么我就不需要这些表(已关闭的旧应用程序)。
案例: 不能用mysqldump做备份,有些表不再需要,而且损坏了
首先我得到损坏表的列表
mysqlcheck --repair --all-databases -u root -p"${MYSQL_ROOT_PASSWORD}" > repair.log
然后我用一个 Python 脚本分析日志,该脚本在 stdin 中获取它(另存为 ex.analyze.py 并执行 cat repair.log| python3 analyze.py)
#!/usr/bin/env python3
import re
import sys
lines = sys.stdin.read().split("\n")
tables = []
for line in lines:
if "Error" in line:
matches = re.findall('Table \'([A-Za-z0-9_.]+)\' doesn', line)
tables.append(matches[0])
print('{', end='')
print(",".join(tables), end='')
print('}', end='')
您将获得损坏的数据库列表。
使用 mysqldump 进行导出
mysqldump -h 127.0.0.1 -u root -p"${MYSQL_ROOT_PASSWORD}" -P 3306 --skip-lock-tables --add-drop-table --add-drop-database --add-drop-trigger --all-databases --ignore-table={table1,table2,table3 - here is output of the previous command} > dump.sql
关闭数据库,将/var/lib/mysql移动到/var/lib/mysql-backup,启动数据库。
在干净的数据库上只需导入 dump.sql,重启数据库,享受一个没有损坏表的实例。
答案 1 :(得分:1)
我最近在一个升级到16.04 LTS的Ubuntu服务器上遇到了类似的问题。在此过程中,MySQL被MariaDB取代,显然旧数据库无法自动转换为兼容格式。安装程序将原始数据库从/var/lib/mysql
移至/var/lib/mysql-5.7
。
有趣的是,原始表结构存在于/var/lib/mysql/[database_name]
文件中的新.frm
下。新的ibdata文件是12M,2个日志文件是48M,我得出结论,数据必须在那里,但后来我发现初始化一个完全空的数据库导致类似的大小,所以&# 39;不是指示性的。
我在VirtualBox上安装了16.04 LTS,在其上安装了MySQL,然后复制了mysql-5.7
目录并将其重命名为mysql
。启动服务器并使用mysqldump
转储所有内容。删除了原始服务器上的/var/lib/mysql
,用mysql_install_db
初始化了一个新的,并从mysqldump导入了sql文件。
注意:我不是最初进行系统升级的人,因此可能会遗漏一些细节,但症状与您的相似,所以这可能会有所帮助。
答案 2 :(得分:0)
对我来说,此问题已解决,方法是转到 / var / lib / mysql (或将原始数据库文件存储在任何地方),并删除该错误未说明的表的.frm文件存在。