几天来我一直在反对这个。我们有两周的生产 mysql 数据目录的每日备份快照（即实际的二进制文件，而不是 sql 转储），我需要从其中一个备份中恢复一个表，以便我们可以将它与我们现在拥有的进行比较.
因此，我创建了一个虚拟模式目录并提取了相关的表文件（.MYI、.MYD 和 .frm）并重新启动了 mysql。它出现了，我可以“显示表格”，但是如果我尝试以任何方式（“desc tablename”、“select...”等）与之交互，我会得到：
找不到文件：'./schema_name/table_name.frm' (errno: 13)
[编辑：真实姓名消毒]
Errno 13 是权限，所以我仔细检查了所有内容。目录和文件与所有其他模式具有相同的所有者和组 (mysql:mysql)。它们也具有相同的权限（目录为 700，文件为 660）。查看“ls -n”，uid 也完全匹配。
最近，我尝试对不同的备份进行完整提取，然后将其链接到 mysql 数据目录（该卷上没有足够的空间来提取完整内容），但出现相同的错误。我还尝试将 my.cnf 中 mysql 的数据目录指向保存备份并重新启动的目录。它构建了需要存在的 mysql 表，但我仍然遇到相同的错误。
我通过谷歌搜索唯一能找到的是因为实际所有权或许可错误而遇到这个问题的人，这对我来说似乎并非如此。我还在传递可能导致此错误的 UMASK 环境变量时发现了一些评论，但我认为这与全新安装有关，而事实并非如此。
mysql ×1