我正在尝试在视窗服务器，我得到以下错误信息：
mysqldump: Got error: 23: Out of resources when opening file '.\db\sometable.MYD' (Errcode: 24) when using LOCK TABLES
这是命令我在跑 ：
mysqldump -u user -p"pass" --lock-tables --default-character-set=latin1 -e --quick databasename > "query.sql"
重新启动 mysql 服务没有帮助。
我总是收到同一张桌子的消息。
我尝试过减少表缓存和最大连接数变量分别从 64 到 32 和从 30 到 10，但我仍然会收到错误，只是这次是针对不同的表（从现在开始错误消息总是提到第二个表）。
同样的脚本正在其他十几个上运行视窗服务器具有相同的数据库而没有问题。
所有数据库都有 85 个表。
答案1
根据这里- “OS 错误代码 24：打开的文件太多”与更常见的错误 23“资源不足”一致。
因此，看起来好像您用完了文件句柄。这通常是服务器端设置/问题，无论是在 MySQL 中，还是在操作系统本身中。
也许检查/调整--open-files-limit环境在 MySQL 本身中查看是否有帮助。
另外，也许可以尝试在没有其他人使用数据库的情况下运行转储，使用--single-transaction环境而不是--Lock-File，因为有几个人建议这样一次只处理一个表，而不是一次打开所有表（因此使用更少的文件句柄）。
除此之外，您可能还必须找到该特定服务器资源耗尽的根本原因。这可能涉及通过禁用尽可能多的服务/进程进行故障排除，并查看转储是否顺利完成。然后从那里找出消耗过多资源且可能未正确释放资源的罪魁祸首。
答案2
您是否可以尝试使用，--single-transaction例如--lock-tables，表是 InnoDB，并且您没有使用 Cluster 表，并且在转储期间不会发生 ALTER TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE？最好与您的 MySQL 支持组织确认这是否没问题（如果有）。
我只在 unix 上尝试过这个，但基本上如果我尝试使用包含 2000 个表的数据库，它就会失败并出现与您的类似错误，例如我已经使用了所有打开的文件句柄。
答案3
你可能会收到此错误：
MySQL：使用 LOCK TABLES 时出现错误代码：24
...当您升级到 MySQL 5.5 并在 Plesk 或任何其他执行的操作系统上运行备份时，还会出现其他错误mysqldump。
修理：
- 编辑
my.cnf 添加：
open_files_limit=2048重启 MySQL
如果您收到：
无法从 mysql.proc 加载。表可能已损坏 (1548)
这是升级到 5.5 的结果。执行：
mysql_upgrade --force
在 CentOS 6.7 和 Plesk 12 上测试并运行。
答案4
我遇到了与 Philipe 类似的问题。当我启动 dump 时，我看到了如下错误：
mysqldump: Got error: 23: Out of resources when opening file './c1baznarz/timecard.MYD' (Errcode: 24) when using LOCK TABLES
我使用了简单的命令：
mysqldump -uroot -p c1baznarz > c1baznarz.sql
因此，我向 mysqldump 添加了另一个命令：
--single-transaction
并且转储已准备就绪。因此，我的所有 mysqldump 查询如下所示：
mysqldump -uroot -p --lock-tables --single-transaction c1baznarz > c1baznarz.sql