錯誤現象

mysqldump: Got error: 1016: Can't open file: './db/tbl.frm' (errno: 24) when using LOCK TABLES

errno: 24 代表「Too many open files」（作業系統檔案描述符耗盡）。

快速解決：關閉鎖表

mysqldump -u root -p --lock-tables=false db_name > dump.sql

• --lock-tables=false 避免 FLUSH TABLES WITH READ LOCK 同時開啟大量表檔案。
• 適用於**僅需邏輯備份、可容忍非一致性快照**的場景（如 MyISAM 混合庫、非事務表）。

根治方案：提高檔案描述符限制

1. 臨時生效（當前 Shell）

ulimit -n 65535

2. 永久生效（系統級）

# /etc/security/limits.conf
mysql soft nofile 65535
mysql hard nofile 65535

# /etc/systemd/system/mysqld.service.d/override.conf (systemd)
[Service]
LimitNOFILE=65535

修改後 systemctl daemon-reload && systemctl restart mysqld。

3. MySQL 內部參數配合

[mysqld]
open_files_limit = 65535
table_open_cache = 4000  # 視表數量調整

進階備份策略建議

策略	優點	缺點	適用場景
--single-transaction (InnoDB)	無鎖、一致性快照	僅限 InnoDB，長事務影響 Undo 回收	全 InnoDB 生產庫
--lock-tables=false	避開檔案描述符限制	無一致性保證，MyISAM 易損壞	混合引擎、非核心庫
Percona XtraBackup	物理熱備、無鎖、速度快	需額外安裝、佔磁碟空間	大型生產庫、嚴格 RPO/RTO
主從架構從庫備份	主庫零影響	需維護從庫、複製延遲風險	高可用架構

總結

遇到 errno: 24 先加 --lock-tables=false 繞過，**根治必須提高 OS 與 MySQL 的檔案描述符上限**。生產環境強烈建議佈署 XtraBackup 或從庫備份，徹底規避邏輯備份的鎖表與效能問題。