mysqldump：出现错误：1146：使用 LOCK TABLES 时表“myDatabase.table”不存在答案

【问题标题】：mysqldump: Got error: 1146: Table ' myDatabase.table' doesn't exist when using LOCK TABLESmysqldump：出现错误：1146：使用 LOCK TABLES 时表“myDatabase.table”不存在
【发布时间】：2017-03-17 17:51:52
【问题描述】：

我正在尝试转储我的数据库：

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

为什么我会收到此错误或如何解决此错误？

非常感谢您的帮助

【问题讨论】：

你确定表名中没有隐藏的字符 ..eg: char fo table name length ..
这可能是文件系统权限问题、数据库损坏或您的数据库从操作系统迁移到其他操作系统失败（例如 macOS/window 到 linux）？您可以尝试的一件事是Repair all tables in one go。如果是 InnoDB 表，那么解决问题可能会更复杂。
看看这个也dba.stackexchange.com/questions/107429/…
@scaisEdge mysqldump 应该使用正确的命名，这可能更多是配置或损坏问题。例如。将配置和/或数据库从不区分大小写的文件系统移动到区分大小写的文件系统。
@scaisEdge，我已经更新了我的问题。

标签： mysql phpmyadmin

【解决方案1】：

对我来说，问题已通过转到 /var/lib/mysql（或存储原始数据库文件的任何位置）并删除错误表示的表的 .frm 文件来解决存在。

【讨论】：

【解决方案2】：

我在服务器上执行 mysqldump 时遇到问题，我意识到如果这些表长时间不使用，那么我不需要那些表（已关闭的旧应用程序）。

案例： 不能用mysqldump做备份，有些表不再需要并且损坏了

首先我得到了损坏表的列表

mysqlcheck --repair --all-databases -u root -p"${MYSQL_ROOT_PASSWORD}" > repair.log

然后我使用 Python 脚本分析日志，该脚本在标准输入（另存为 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，重启数据库，享受没有损坏表的实例。

【讨论】：

【解决方案3】：

我最近在升级到 16.04 LTS 的 Ubuntu 服务器上遇到了类似的问题。在此过程中，MySQL 被 MariaDB 取代，显然旧数据库无法自动转换为兼容格式。安装程序将原始数据库从/var/lib/mysql 移动到/var/lib/mysql-5.7。

有趣的是，原始表结构出现在 .frm 文件中的新 /var/lib/mysql/[database_name] 下。新的 ibdata 文件为 12M，2 个日志文件为 48M，从中我得出结论，数据必须在那里，但后来我发现初始化一个完全空的数据库会导致类似的大小，所以这不是指示性的。

我在 VirtualBox 上安装了 16.04 LTS，在上面安装了 MySQL，然后复制了 mysql-5.7 目录并将其重命名为 mysql。启动服务器并使用mysqldump 转储所有内容。删除原服务器上的/var/lib/mysql，用mysql_install_db初始化一个新的，并从mysqldump导入sql文件。

注意：我不是最初做系统升级的人，所以可能遗漏了一些细节，但症状与你的相似，所以也许这会有所帮助。

【讨论】：