我已经为此苦思冥想了好几天了。我们有两周的生产 mysql 数据目录的每日备份快照（即实际的二进制文件，而不是 sql 转储），我需要从其中一个备份中恢复一个表，以便我们可以将其与现在的表进行比较。
因此，我创建了一个虚拟架构目录并提取了相关的表文件（.MYI、.MYD 和 .frm），然后重新启动了 mysql。它出现了，我可以“显示表”，但如果我尝试以任何方式与它交互（“desc tablename”、“select...”等），我会得到：
找不到文件：'./schema_name/table_name.frm'（错误号：13）
[编辑：真实姓名已净化]
Errno 13 是权限，所以我仔细检查了所有内容。目录和文件与所有其他架构具有相同的所有者和组 (mysql:mysql)。它们还具有相同的权限（目录上为 700，文件上为 660）。查看“ls -n”，uid 也完全匹配。
最近，我尝试对另一个备份进行完整提取，然后将其链接到 mysql 数据目录（该卷上没有足够的空间来提取完整内容），但还是出现了同样的错误。我还尝试将 my.cnf 中的 mysql 数据目录指向保存备份的目录并重新启动。它构建了需要存在的 mysql 表，但我仍然遇到了同样的错误。
我通过谷歌搜索找到的唯一信息是，有人因为实际所有权或权限错误而遇到此问题，而我的情况似乎并非如此。我还顺便发现了一些关于 UMASK 环境变量可能导致此错误的注释，但我思考这与全新安装有关，但事实并非如此。
答案1
您是否正在运行 selinux 之类的程序或其他类似的程序包？我建议禁用它（或修改安全策略）以查看是否有东西阻止 MySQL 访问文件。
[编辑] 如果是，请检查 syslog 以查看 selinux 是否阻止 mysql 执行任何操作。如果是 SELinux，我被告知这可能会禁用它，以便您可以测试这个理论。
/usr/sbin/setenforce Permissive
答案2
在这种情况下，strace 是你的好朋友。找到你的 mysql 的进程 id，然后运行：
strace -efile -f -o /tmp/mysql.log -p $pid
在另一个窗口中执行导致错误的操作。然后您可以按 ctrl-c 来终止 strace。如果您查看 /tmp/mysql.log，您应该会看到导致问题的原因。
另外，我真的建议您不要依赖复制二进制数据文件。SQL 转储更加可靠和灵活。此外，看起来您正在使用 MyISAM。除非您不关心其中的数据，否则我真的不建议您使用它们。InnoDB 比 MyISAM 有很多优势。
答案3
我最近遇到了这个问题，我通过将数据库目录中每个人的数据库目录权限更改为/var/lib/mysql如下方式解决了这个问题：
PWD: /var/lib/mysql
chmod u+x schema_db1
chmod u+x schema_db2
chmod u+x schema_db3
chmod u+x schema_db4
重新启动 MySQL 引擎，即可再次运行！希望这对您有用。
答案4
检查配置的用户名是什么/etc/my.cnf
[mysqld]
bind-address=<IP Address>
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=<username>
可能根或者您已配置的。我修改为根它开始为我工作了。
然后启动mysql
service mysqld stop
service mysqld start